I feel like learning is a continuous process, technology changes from time to time so might stay updated with all the latest trend.
How I became a better programmer (2017)
71–80 of 150 posts
Re: How I became a better programmer (2017)
#72Earlier quoted context omitted.
Exactly. I had coworkers like this, and their code was impossible to understand. To make a simple change to it, it would require days of refactoring just to know you weren't going to introduce a bug. It's not being more productive, it just seems that you're getting things done faster because you're taking out a loan on the quality of your software (i.e. technical debt) with every line you write.
How old is the software and what's the change that needed. If the software is past it's ROI and changes are happening due to scope creep then days of refactoring isn't refactoring it's just days of dev work against new requirements. It's just happening on an old product. Management may be willing to spend that time and not be unhappy with what you perceive as time wasted because they have seen greater than expected R…
I've ran into these problems with software that wasn't even released yet. Some of these practices will likely bite you in the ass in months or even weeks, not years.
Re: How I became a better programmer (2017)
#73My comment is a little tongue in cheek but Here is "How I became a more productive by becoming a worse programmer" - I stopped worrying about best practices and just do it. - I hardly refactor my code unless I'm using the same thing for the fifth time. I just copy-paste it instead. - I never think about optimizing code until I really really need to. - I write what gets the shit done quickly. I don't care if writing a…
Not to be rude or anything but if you continue down this road productivity might be the only thing going for you and you'll soon realise you are the only one who can work with your code. Substitute software engineering with any other engineering descipline with "I stopped worrying about best practices" and you will be able to see what's wrong with your approach. But then again, if it's php, your domain doesn't requir…
Although I agree in general, a 10 line for loop is usually more readable than a clever one liner.
Re: How I became a better programmer (2017)
#74Earlier quoted context omitted.
How old is the software and what's the change that needed. If the software is past it's ROI and changes are happening due to scope creep then days of refactoring isn't refactoring it's just days of dev work against new requirements. It's just happening on an old product. Management may be willing to spend that time and not be unhappy with what you perceive as time wasted because they have seen greater than expected R…
I've ran into these problems with software that wasn't even released yet. Some of these practices will likely bite you in the ass in months or even weeks, not years.
They generally get the next person to work in the code without understanding what was going through your head: and 90% of the time, that’s you, three days from now.
Re: How I became a better programmer (2017)
#75Earlier quoted context omitted.
> then languages Perhaps a slight digression, but: I think there are very few people who can really say they can 'see through' the difference between languages. C++, Erlang, Prolog, and Haskell, are very different languages, all the way from the shallow matter of syntax, through the type system, and even down to the fundamental model of computation. When I hear someone say If you learn to program in one language, it'…
> If you learn to program in one language, it's easy to learn another, I assume that person doesn't know much about programming. This is flat out wrong. If you know Python, it'll be easier to learn Rust than having to learn Rust from zero. Engineering is about problem solving and formulating solutions with algorithms and data structures. If you don't know what those are yet, it'll take much longer to learn. Learning…
Learning Python before Haskell also made learning Haskell significantly harder for me, because I kept trying to write Python in Haskell
Re: How I became a better programmer (2017)
#76Re: How I became a better programmer (2017)
#77My comment is a little tongue in cheek but Here is "How I became a more productive by becoming a worse programmer" - I stopped worrying about best practices and just do it. - I hardly refactor my code unless I'm using the same thing for the fifth time. I just copy-paste it instead. - I never think about optimizing code until I really really need to. - I write what gets the shit done quickly. I don't care if writing a…
“and believe you can still make amazing websites with just PHP and jQuery.”
Found the Magento developer.
Re: How I became a better programmer (2017)
#78Earlier quoted context omitted.
> then languages Perhaps a slight digression, but: I think there are very few people who can really say they can 'see through' the difference between languages. C++, Erlang, Prolog, and Haskell, are very different languages, all the way from the shallow matter of syntax, through the type system, and even down to the fundamental model of computation. When I hear someone say If you learn to program in one language, it'…
I would expand that to "If you learn to program in one language, it's easy to learn another within the same paradigm" . If you know Python, Ruby or PHP will be pretty easy for you to pick up. You might have some difficulties with Haskell and Lisp.
I'd add that spending some time to play with the languages that are hard or different will pay dividends down the road.
Learning some Haskell was probably the most worthwhile time I have spent learning a language because it forced me to fundamentally reevaluate how I think about programming. Now I don't use Haskell at work, and likely never will; but, years later, the techniques I learned from it I still apply daily when I write C, Python, JS or whatever. It made my code far cleaner.
Re: How I became a better programmer (2017)
#79My comment is a little tongue in cheek but Here is "How I became a more productive by becoming a worse programmer" - I stopped worrying about best practices and just do it. - I hardly refactor my code unless I'm using the same thing for the fifth time. I just copy-paste it instead. - I never think about optimizing code until I really really need to. - I write what gets the shit done quickly. I don't care if writing a…
> I never think about optimizing code until I really really need to.
The point of 'really really need to' has long been passed and you didn't notice it.
(Unless you use an entry-level $200 notebook for development, which you probably don't.)
In other words, please please eat your own dogfood. Your users aren't browsing your 'amazing websites' with a development notebook.
Re: How I became a better programmer (2017)
#80Earlier quoted context omitted.
Exactly. I had coworkers like this, and their code was impossible to understand. To make a simple change to it, it would require days of refactoring just to know you weren't going to introduce a bug. It's not being more productive, it just seems that you're getting things done faster because you're taking out a loan on the quality of your software (i.e. technical debt) with every line you write.
"It's not being more productive, it just seems that you're getting things done faster because you're taking out a loan on the quality of your software (i.e. technical debt) with every line you write." This. When someone does this in a hurry or because they didn't know better, it's understandable. But when someone thinks that this style of working is superior, that's a huge problem.
Paying down tech debt is like brushing your teeth, if you don't do it regularly, you'll end up with more pain and a higher bill at the end.