5 ms·

I disagree, if you consistently think that the code you wrote a year ago is shit then you are probably just chasing a new fad every year. I'd say that if a juni

I disagree, if you consistently think that the code you wrote a year ago is shit then you are probably just chasing a new fad every year. I'd say that if a junior developer with a year in a language doesn't write code he can rightfully be proud of then he is focusing on the wrong things.

braveo 10y ago
thank you, I say the same thing every time I see this come up. That's a young mans game, after you've been doing this stuff long enough the things you learn are in terms of systems design, maintenance, etc. I regularly go back to code I wrote 2 and 3 years ago and think to myself "knowing what I know now, that code is mostly alright". I can't understand how someone can go back and look at some authentication code, for example, and think the way they did it was horrible. Just how many different ways can you write auth code? It's one thing if you're a young developer, but at some point the improvements to your code are negligible and have nothing to do with the value you bring to a project.
- Fifer82 10y ago
  Where do you guys get a job without any time constraints? Also were you born with all knowledge? You are saying for example that the booking system you made in 2009, which was the first time you ever "programmed time" is pretty much perfect? (change the example to shaders, or physics, or your first Node back end blah blah). I am calling Bullshit.
  - braveo 10y ago
    I would think the ones who constantly go back and worry about old code are the ones you would accuse of having no time constraints. The thing is, if you're going back to the first time you've ever "programmed time", then what you're assessing is design, not code, which falls in line with what I said.
- tomgp 10y ago
  Yes, the scale at which you notice problems with older code changes as you gain experience. i.e. you may have it down at a function or class level but then, at a system design level, or perhaps in the way that the code addresses business needs there will likely be improvements that you can see given the benefit of hindsight and experience. [edited to remove typo]
- deleted 10y ago
  [deleted]
- hinkley 10y ago
  I didn't say I still think my old code is horrible (well, some of it is). I said I wouldn't do it that way again. That's more like, "Well this is alright, I guess, but..."
falcolas 10y ago
Meh, I've been doing this for around 10 years now, and I dislike code I wrote yesterday. It's not wrong, it's just merely sufficient. Why? To paraphrase someone else: I wrote sufficient code because I didn't have the time to write good code. There's always a better abstraction I could have teased out, a more complete refactor to make that one line hack never have to exist, and better documentation which would read more like English and less like shorthand.
- chadgeidel 10y ago
  "I made this one [letter] longer only because I have not had the leisure to make it shorter." - Blaise Pascal. https://en.wikiquote.org/wiki/Blaise_Pascal https://en.wikiquote.org/wiki/Blaise_Pascal
- laythea 10y ago
  Yep I second this. This is, in my opinion, what defines a senior level software engineer - the ability to tradeoff where necessary and possible.
zeroxfe 10y ago
You know you can actually improve year-over-year without chasing a new fad. (I'm saying this as someone who's been coding in C++ for over two decades, while still finding lots of room for improvement in my older code.)
- osullivj 10y ago
  25 years of C++ myself. Back in the 90s I coded up all the grossest memory management blunders many times over. Long time since I produced one of those; these days I'm capable of producing some exquisitely subtle synchronisation and threading bugs ;)
- laythea 10y ago
  I think the key is to study principles/concepts, not implementations.
  - cestith 10y ago
    One should have a solid grounding in principles and concepts. Try shipping principles and concepts at the end of the quarter, though.
deleted 10y ago
[deleted]
hinkley 10y ago
Much of the time what I'm learning today is how to write code that is obviously correct or obviously wrong to everyone who looks at it. It's not prima facie 'better' than the code I wrote before, but it's more likely for the original intent to survive multiple modifications by others, and emergency fixes are less dramatic. The analogy I'm experimenting with now is stage performers for Opera or Musical productions. If you see them up close, such as video recording, they clearly 'overact'. They use exaggerated facial and arm expressions to project their performance far enough so the people in the middle or even the back can see what's going on. They are expanding the audience greatly, but admittedly at the expense of those closest to the action. But on the whole it's a better performance. When I find bugs in my code, introduced by me or added by someone else, I think about how it looked before and try to determine if it was just a dumb mistake or whether I tricked them into it. Maybe I grouped the code oddly, or chose an unfortunate variable name that implied something else was going on. If it's the latter I think about whether I really want to use that pattern anymore. What's tricky is that everyone tries to make their code look like the existing code, so people may be copying the pattern thinking it'll get them a clean code review. If I think the problem is bad enough I may stop and refactor all the places it's used (it only works if you're really, really practiced at refactoring), otherwise I'll just make a note so stop doing that in the future. I might mention it in a team retro. I want my code to be as plain as it can be and still get the job done. Indeed at this point I positively fume when a 'senior' developer writes clever code, because they should know by now this isn't about them and they're hurting the entire team trying to fluff up their own ego. Look how important I am that you need me to fix all the really hard bugs. Fuck that, and fuck your dazzling bullshit. The only thing that pisses me off more is a manager that thinks 'blame allocation' is a viable management style.

braveo 10y ago

thank you, I say the same thing every time I see this come up. That's a young mans game, after you've been doing this stuff long enough the things you learn are in terms of systems design, maintenance, etc. I regularly go back to code I wrote 2 and 3 years ago and think to myself "knowing what I know now, that code is mostly alright". I can't understand how someone can go back and look at some authentication code, for example, and think the way they did it was horrible. Just how many different ways can you write auth code? It's one thing if you're a young developer, but at some point the improvements to your code are negligible and have nothing to do with the value you bring to a project.

Fifer82 10y ago
Where do you guys get a job without any time constraints? Also were you born with all knowledge? You are saying for example that the booking system you made in 2009, which was the first time you ever "programmed time" is pretty much perfect? (change the example to shaders, or physics, or your first Node back end blah blah). I am calling Bullshit.
- braveo 10y ago
  I would think the ones who constantly go back and worry about old code are the ones you would accuse of having no time constraints. The thing is, if you're going back to the first time you've ever "programmed time", then what you're assessing is design, not code, which falls in line with what I said.
tomgp 10y ago
Yes, the scale at which you notice problems with older code changes as you gain experience. i.e. you may have it down at a function or class level but then, at a system design level, or perhaps in the way that the code addresses business needs there will likely be improvements that you can see given the benefit of hindsight and experience. [edited to remove typo]
deleted 10y ago
[deleted]
hinkley 10y ago
I didn't say I still think my old code is horrible (well, some of it is). I said I wouldn't do it that way again. That's more like, "Well this is alright, I guess, but..."

falcolas 10y ago

Meh, I've been doing this for around 10 years now, and I dislike code I wrote yesterday. It's not wrong, it's just merely sufficient. Why? To paraphrase someone else: I wrote sufficient code because I didn't have the time to write good code. There's always a better abstraction I could have teased out, a more complete refactor to make that one line hack never have to exist, and better documentation which would read more like English and less like shorthand.

chadgeidel 10y ago
"I made this one [letter] longer only because I have not had the leisure to make it shorter." - Blaise Pascal. https://en.wikiquote.org/wiki/Blaise_Pascal https://en.wikiquote.org/wiki/Blaise_Pascal
laythea 10y ago
Yep I second this. This is, in my opinion, what defines a senior level software engineer - the ability to tradeoff where necessary and possible.

zeroxfe 10y ago

You know you can actually improve year-over-year without chasing a new fad. (I'm saying this as someone who's been coding in C++ for over two decades, while still finding lots of room for improvement in my older code.)

osullivj 10y ago
25 years of C++ myself. Back in the 90s I coded up all the grossest memory management blunders many times over. Long time since I produced one of those; these days I'm capable of producing some exquisitely subtle synchronisation and threading bugs ;)
laythea 10y ago
I think the key is to study principles/concepts, not implementations.
- cestith 10y ago
  One should have a solid grounding in principles and concepts. Try shipping principles and concepts at the end of the quarter, though.

deleted 10y ago

[deleted]

hinkley 10y ago

Much of the time what I'm learning today is how to write code that is obviously correct or obviously wrong to everyone who looks at it. It's not prima facie 'better' than the code I wrote before, but it's more likely for the original intent to survive multiple modifications by others, and emergency fixes are less dramatic. The analogy I'm experimenting with now is stage performers for Opera or Musical productions. If you see them up close, such as video recording, they clearly 'overact'. They use exaggerated facial and arm expressions to project their performance far enough so the people in the middle or even the back can see what's going on. They are expanding the audience greatly, but admittedly at the expense of those closest to the action. But on the whole it's a better performance. When I find bugs in my code, introduced by me or added by someone else, I think about how it looked before and try to determine if it was just a dumb mistake or whether I tricked them into it. Maybe I grouped the code oddly, or chose an unfortunate variable name that implied something else was going on. If it's the latter I think about whether I really want to use that pattern anymore. What's tricky is that everyone tries to make their code look like the existing code, so people may be copying the pattern thinking it'll get them a clean code review. If I think the problem is bad enough I may stop and refactor all the places it's used (it only works if you're really, really practiced at refactoring), otherwise I'll just make a note so stop doing that in the future. I might mention it in a team retro. I want my code to be as plain as it can be and still get the job done. Indeed at this point I positively fume when a 'senior' developer writes clever code, because they should know by now this isn't about them and they're hurting the entire team trying to fluff up their own ego. Look how important I am that you need me to fix all the really hard bugs. Fuck that, and fuck your dazzling bullshit. The only thing that pisses me off more is a manager that thinks 'blame allocation' is a viable management style.