4 ms·

The most obvious way to improve your coding is to write more code. This is a bit too simple: writing more of the same, in the same style, usually won't cut it

by stinos 10y ago

The most obvious way to improve your coding is to write more code. This is a bit too simple: writing more of the same, in the same style, usually won't cut it and unfortunately I've seen people being stuck like that for years: always producing more code, without any improvement whatsoever and instead just repeating the same mistakes. Once those mistakes become a habit they are extra hard to get rid of. So actually writing more code can be worse :] What you really should be doing is write more and from time to time different code, combined with learning through either reading others' or continuously asking yourself 'how can I improve this' followed by e.g. a trip to StackOverflow to find out.

z3t4 10y ago
I want to recommend everyone who sit infront of a screen for several hours per day to invest a few hundred dollars extra on the monitor. The extra contrast makes a huge difference.
- sundvor 10y ago
  Ditto. I bought a 34" 3440x1440 a few years ago - the Dell U3415W. Not long after I made the switch to Visual Studio and C# about a year ago, I bought another - the Acer Predator X34, and took the Dell to work. They're just awesome for programming, as well as other purposes if or when time avails.
iarejenius 10y ago
Exactly. It's like claiming that because I drive to work every day I can eventually become a racecar driver.
taeric 10y ago
Depends what you are wanting to achieve, to be honest. Writing the same code can help make you faster at writing that code. This can be annoying to people who are higher level coders, but the reality is that intrinsic quality of code is easy to complain about, but hard to model the importance of. In large because its importance is quite low. That is, if what they are writing works, despite having what could be seen as mistakes to a more disciplined practitioner, then what is the problem? Consider, someone that has put together Ikea cabinets every week for the past year is probably hella fast at it by now. Can they replace a carpenter? Doubt it. Are they bad at what they do? Doubt it.
- stinos 10y ago
  That is, if what they are writing works, You make a good point, but imo in real life there is more nuance to it than just works/doesn't work. Which again I've seen with the same collegues: the software works, sort of, yes. Despite some annoyances and known bugs and corresponding workarounds it does what it's supposed to do. But it's oh so brittle. So while you could argue that it works so there is no problem, in fact there is: on every single change which has to be made half of the software falls apart and it takes insane amounts of patching to hold things together. Sure, afterwards it works again, but adding more of the same code, no matter how fast it was written, made things surely not better. I admit this is of course like the worst example and I'm sure there are indeed occasions where the code quality doesn't have that much of an impact. For instance especially in small applications/tools/extensions this is true.
  - taeric 10y ago
    I completely agree that it is complicated. The whole debate is strewn with staw men, which does little to help move things along. Still, fun to think about. If you know of any studies, I'm interested.
yellowapple 10y ago
This is a good reason why becoming a "polyglot" probably does more good than harm. Many languages are often better suited to different programming styles or paradigms or problem sets or environments than other languages; learning a new language can help better understand a new concept, thus improving one's ability in general across all languages.
sbov 10y ago
Write more and reflect on what you've written. I've come to have a dev diary where I reflect on what I did the past day/week, and note things I ran across that did/didn't work out so well, and why. That said, if all you're doing is greenfield development I don't think it's actually possible to improve without third party input. A major goal of good code is maintainability, and that can only actually be known in hindsight.
joshuacc 10y ago
Note that the author didn't claim that it was the best way, or that it might not have drawbacks, just that it's the most obvious.
Jugurtha 10y ago
>This is a bit too simple: writing more of the same, in the same style I think the author means there's a correlation between the amount of code one writes and their progress. For a more complete view, there's the often cited article The Role of Deliberate Practice in the Acquisition of Expert Performance[0] where the authors make a point that it's not just practice that makes perfect, but deliberate practice. They set to find and explain patterns exceptional people follow. What you're talking about is what someone who says they have 20 years of experience but, in reality, they have 6 months of experience they've been repeating 40 times. [0]: http://projects.ict.usc.edu/itw/gel/EricssonDeliberatePracticePR93.PDF http://projects.ict.usc.edu/itw/gel/EricssonDeliberatePracti...
thecupisblue 10y ago
Exactly. I've found that my development skills leaped to another level when I tried out some functional languages. Since then my code is more readable, more concise and has less side-effects. Now looking for the next step.

by stinos 10y ago

z3t4 10y ago

I want to recommend everyone who sit infront of a screen for several hours per day to invest a few hundred dollars extra on the monitor. The extra contrast makes a huge difference.

sundvor 10y ago
Ditto. I bought a 34" 3440x1440 a few years ago - the Dell U3415W. Not long after I made the switch to Visual Studio and C# about a year ago, I bought another - the Acer Predator X34, and took the Dell to work. They're just awesome for programming, as well as other purposes if or when time avails.

iarejenius 10y ago

Exactly. It's like claiming that because I drive to work every day I can eventually become a racecar driver.

taeric 10y ago

Depends what you are wanting to achieve, to be honest. Writing the same code can help make you faster at writing that code. This can be annoying to people who are higher level coders, but the reality is that intrinsic quality of code is easy to complain about, but hard to model the importance of. In large because its importance is quite low. That is, if what they are writing works, despite having what could be seen as mistakes to a more disciplined practitioner, then what is the problem? Consider, someone that has put together Ikea cabinets every week for the past year is probably hella fast at it by now. Can they replace a carpenter? Doubt it. Are they bad at what they do? Doubt it.

stinos 10y ago
That is, if what they are writing works, You make a good point, but imo in real life there is more nuance to it than just works/doesn't work. Which again I've seen with the same collegues: the software works, sort of, yes. Despite some annoyances and known bugs and corresponding workarounds it does what it's supposed to do. But it's oh so brittle. So while you could argue that it works so there is no problem, in fact there is: on every single change which has to be made half of the software falls apart and it takes insane amounts of patching to hold things together. Sure, afterwards it works again, but adding more of the same code, no matter how fast it was written, made things surely not better. I admit this is of course like the worst example and I'm sure there are indeed occasions where the code quality doesn't have that much of an impact. For instance especially in small applications/tools/extensions this is true.
- taeric 10y ago
  I completely agree that it is complicated. The whole debate is strewn with staw men, which does little to help move things along. Still, fun to think about. If you know of any studies, I'm interested.

yellowapple 10y ago

This is a good reason why becoming a "polyglot" probably does more good than harm. Many languages are often better suited to different programming styles or paradigms or problem sets or environments than other languages; learning a new language can help better understand a new concept, thus improving one's ability in general across all languages.

sbov 10y ago

Write more and reflect on what you've written. I've come to have a dev diary where I reflect on what I did the past day/week, and note things I ran across that did/didn't work out so well, and why. That said, if all you're doing is greenfield development I don't think it's actually possible to improve without third party input. A major goal of good code is maintainability, and that can only actually be known in hindsight.

joshuacc 10y ago

Note that the author didn't claim that it was the best way, or that it might not have drawbacks, just that it's the most obvious.

Jugurtha 10y ago

>This is a bit too simple: writing more of the same, in the same style I think the author means there's a correlation between the amount of code one writes and their progress. For a more complete view, there's the often cited article The Role of Deliberate Practice in the Acquisition of Expert Performance[0] where the authors make a point that it's not just practice that makes perfect, but deliberate practice. They set to find and explain patterns exceptional people follow. What you're talking about is what someone who says they have 20 years of experience but, in reality, they have 6 months of experience they've been repeating 40 times. [0]: http://projects.ict.usc.edu/itw/gel/EricssonDeliberatePracticePR93.PDF http://projects.ict.usc.edu/itw/gel/EricssonDeliberatePracti...

thecupisblue 10y ago

Exactly. I've found that my development skills leaped to another level when I tried out some functional languages. Since then my code is more readable, more concise and has less side-effects. Now looking for the next step.