Absolute truths I unlearned as junior developer(monicalent.com)
monicalent.com
Absolute truths I unlearned as junior developer
https://monicalent.com/blog/2019/06/03/absolute-truths-unlearned-as-junior-developer/
533 comments
> code that I wrote myself is hard to read
This has happened more times than it probably should:
1. Arrive upon some code I wrote at some point in the near or distant past.
2. Review it to get some idea of what I was trying to do
3. Laugh at my young self for being so naive
4. Refactor or Rewrite
5. Re-realize the edge-cases and difficulties
6. Remember this being a problem
7. Refactor And Rewrite
8. Either `git reset --hard HEAD` or end up with a similar solution, but with better comments
Once in a while, I end up with a [simpler | faster | clearer | otherwise better] version, which makes this process worth while - even with the false positives.
This has happened more times than it probably should:
1. Arrive upon some code I wrote at some point in the near or distant past.
2. Review it to get some idea of what I was trying to do
3. Laugh at my young self for being so naive
4. Refactor or Rewrite
5. Re-realize the edge-cases and difficulties
6. Remember this being a problem
7. Refactor And Rewrite
8. Either `git reset --hard HEAD` or end up with a similar solution, but with better comments
Once in a while, I end up with a [simpler | faster | clearer | otherwise better] version, which makes this process worth while - even with the false positives.
Semi-related story of mine:
1. Stumble upon some specific problem with a web framework we use.
2. Jump straight to stackoverflow.
3. Sbd had a similar issue, nice.
4. Sbd wrote a very concise answer, nice too.
5. There's my nickname under the answer. Oh, wait...
1. Stumble upon some specific problem with a web framework we use.
2. Jump straight to stackoverflow.
3. Sbd had a similar issue, nice.
4. Sbd wrote a very concise answer, nice too.
5. There's my nickname under the answer. Oh, wait...
I'm getting the statement about once a quarter at work of:
Yeah I found this bug and I worked through it, did a bunch of googling or internal searching found a similar issue and welp it was a ticket from you (me) 2 years ago.
Yeah I found this bug and I worked through it, did a bunch of googling or internal searching found a similar issue and welp it was a ticket from you (me) 2 years ago.
Which is why I am trying to get better at what I used to to: writing down and sharing problems I saw.
I have a giant dev file (well, 2 really: 1 for personal, 1 for work) that I use as a scratchpad. Anything I work on goes there. Makes it easy to find things.
Monthly I pull out useful things into notes about that topic. Run into a weird problem with spring framework? Copy out the relevant info into springframework.md.
Monthly I pull out useful things into notes about that topic. Run into a weird problem with spring framework? Copy out the relevant info into springframework.md.
It drives me nuts when you find a forum post and they never reported back. Or it's a terse "I figured it out."
I try really hard not to do that for internal or public forums. The odds are better than you think that you'll stumble on the same topic a few years from now.
I try really hard not to do that for internal or public forums. The odds are better than you think that you'll stumble on the same topic a few years from now.
Or it say "Google it" and thats how you ended up there.
Wisdom of the Ancients
https://xkcd.com/979/
https://xkcd.com/979/
I try to at least move the problem forward. However does anyone have a way they make sure to close those things out and circle back? I mean other than just doing it?
On internal tools I do do that but that's a smaller number.
Worse is stuff like car and fridge repair. I have no idea what forum I find qqs on.
On internal tools I do do that but that's a smaller number.
Worse is stuff like car and fridge repair. I have no idea what forum I find qqs on.
I'm sad that I cannot share my experiences the same way :-( 99% of my "interesting" bugs are almost all Xbox One/PS4 related, so I can't write a blog post about "how I found out that Sony's implementation of file read is not compatible with regular stdio" - it's hugely interesting but this stuff is NDA'd to such an extent that I wouldn't risk writing openly about it - but I'd love to.
I've found a good way to do that is running a personal blog. In fact, I write as if the audience of my blog will be myself in the future. It's nice to help out others who face the same problem tho.
Does "Sbd" stand for something, or is that your username?
The abbreviation "sth" occurs here a lot, probably because of people who learned English with the help of dictionaries that use "sth" as an abbreviation for "something". I suspect "sbd" also comes from the same source.
[deleted]
Somebody
Uh, OK. Never seen that before.
"Sby" would've made way more sense. Or heaven forbid we use one more character to make the nearly obvious "sbdy."
"Sby" would've made way more sense. Or heaven forbid we use one more character to make the nearly obvious "sbdy."
It's a recurring theme with me, though a bit different where my name is under step 3, and I only realized that when I tried to upvote the question and couldn't.
Heh, that happened to me too... I loved it.
THANK YOU!!!
I really thought this only happened to me :-)
I really thought this only happened to me :-)
Have experienced this too. Haha.
SO is my notebook.
This.
Why create my own silo of documentation when I can just put the answer where I'm likely going to find it (Stack Overflow).
Why create my own silo of documentation when I can just put the answer where I'm likely going to find it (Stack Overflow).
This is probably the primary actual use case for comments. Explain why something is done the way it is; to justify to those who come after why Chesterton's Fence [1] should apply in this case.
[1] https://wiki.lesswrong.com/wiki/Chesterton%27s_Fence
[1] https://wiki.lesswrong.com/wiki/Chesterton%27s_Fence
Yes.
In a wider sense, you also want to explain why something is NOT done. Ie why certain other ideas don't work, or why we don't offer certain features.
In a wider sense, you also want to explain why something is NOT done. Ie why certain other ideas don't work, or why we don't offer certain features.
Same idea should apply to laws. The why gets forgotten a half century later because the problem was solved but not well documented. Because the problem is no longer happening, they think the law must no longer be necessary.
As a counterpoint, we often end up with laws, traditions, and social mores that long outlive whatever rationale they had for them in the first place. (Assuming they had a rationale, and weren’t just based on fear and superstition).
That someone being me not knowing why in hell would I write this monstrosity... git blame + some archeology work to get jira ticket number (I put issue numbers in commit message/branch name) and from that I know why.
Yes, naturally "those who come after" often includes the future you.
Much of my life as an older dev includes balancing my relationship with my past, current, and future selves. Be kind to your future self; be compassionate of your past self. And don't forget, they really are different people ;)
Here's what happened to me(A) and a friend(B) from a former workplace of mine(open-source project):
B: Take a look at this shit code that I found.
A: Whoah, it really is shit. Blame it so that we can see what kind of genious is behind this.
B: ...
A: Well?
B: Apparently you wrote and I reviewed/approved it.
B: Take a look at this shit code that I found.
A: Whoah, it really is shit. Blame it so that we can see what kind of genious is behind this.
B: ...
A: Well?
B: Apparently you wrote and I reviewed/approved it.
The "who wrote this?" mentality is a trap that's good to avoid. Get comfortable with different ways of writing something that, while they might have different tradeoffs, accomplish the same thing, and try to see past that. Understand that most code wasn't written by anybody--lines 1 and 3 were written by Alice a year ago, line 2 was written by Bob 2 years ago, and line 4 was written by Alice yesterday. `git blame` is very useful for seeing the change in context, which can give a lot of insight into why it's written that way, but usually the author isn't very useful to know, unless you're planning to ask them about it. Sometimes it's useful if you happen to know that the author isn't very familiar with something when you're wondering why they didn't use it, but try to keep in mind what the actual benefits of your way are, whether they're especially pressing, and that the other person might have written it differently because they were thinking about other concerns that you forgot.
I agree that “who wrote this” is dangerous, and git blame is a terribad name. I will say though, if you can avoid value judgements, then knowing who wrote a block of code is super valuable in a legacy code base. I’ve found that every dev I’ve ever worked with has very real strengths and weaknesses. And knowing who wrote a piece of code can drastically reduce the time it takes me to find hard bugs. It often goes something like, so and so tends to forget certain kinds of edge cases, but they never seem to screw up this kind of logic... so I bet the problem is related to... ah found the problem. But never blame someone for creating bugs, unless it’s really egregious, and then, only if you can help them with better habits going forwards.
Yes, "blame" is not a good word.
Use "git annotate" instead.
Use "git annotate" instead.
I really like this approach of using git blame, it's original thinking and highlights how much human components there are in developing.
While lots of legacy code emerges organically the way you describe, there are in fact many people in the industry who I'd call "legacy coders." People who saw Dijkstra's "Goto considered harmful" and scoffed, "all these 'for' loops are much less readable than my 'goto loop1' solution." People who use global variables because parameter-based implementations are "needlessly complex."
Basically, not everyone works for Google.
Basically, not everyone works for Google.
You say that, but Golang has gotos, while being a very minimal language. Not everyone at Google is an amazing developer that's fully up to date with best practices and patterns.
Not that that needs to be said, no matter the company (if it's of any decent size.)
Not that that needs to be said, no matter the company (if it's of any decent size.)
It’s often helpful to know who wrote a line of code, because then I can put myself into their shoes and try to figure out what was going on their mind when they wrote it.
[deleted]
I’ve always found the svn alias ‘svn praise’ pretty entertaining for this reason.
git has "git annotate"
Assuming those lines were getting out of hand, I think it would be a valid question as to why they were not tidied up during the review of the line 4 addition by Alice.
It’s Friday afternoon, you are exhausted after a busy week, the business is pushing for a fix before you leave and you have committed to be home by 6pm so your spouse can go out.
`git log -p` is vastly superior to `git blame` for determining why a file is the way it is.
That gives you all the history (or all the history of a file).
Git blame quickly gives you the commits you are likely interested in, then you can use them as a starting point for your git log digging.
Git blame quickly gives you the commits you are likely interested in, then you can use them as a starting point for your git log digging.
I've had that happen several times, but once I actually did the inverse.
I was working on an extraordinarily bad codebase, and stumbled upon some modular, reusable code that made my life way easier. I wondered who wrote this rare gem in that pile of shit, and checked `svn praise` for a change.
It was me.
It would have been the highlight of my then short career, if not for the fact that it meant there were no other semi-competent people on that project.
I was working on an extraordinarily bad codebase, and stumbled upon some modular, reusable code that made my life way easier. I wondered who wrote this rare gem in that pile of shit, and checked `svn praise` for a change.
It was me.
It would have been the highlight of my then short career, if not for the fact that it meant there were no other semi-competent people on that project.
This is really funny. So good. I ask all the time, "Who wrote this shit??" knowing it was probably me.
Honestly, this is usually a good sign. I'll code at the edge of my current skill. Six months from now, I hope I can look at that code and consider it primitive from where I hope to be then.
That is the only time I dare ask it. When else do I dare? Someone might take it the wrong way otherwise.
*genius
These days my rule of thumb is to not try to rewrite or generalize until I or my team has tried to do more or less the same thing three times. Before that, you just don't have a good feel for what is generalizable/edge case or what is invariant/variable in the problem space.
I've definitely run into this phenomenon of independently landing on the same design twice because of the same edge cases. At some point back in 2005 or so, I was working on a collision detection component for a physics engine. This was 1-2 years before the Box2D engine, so there was a significant lack of any open source options, so I was rolling my own stuff that was quite similar to Box2D (but Box2D was written much better).
One year later, I came back, looked at the code, thought "this is unreadable!" refactored it, and sure enough, stuff was falling through floors. I went back to my old code, found several comments discussing edge cases having to do with discrete time step problems, and concluded that my old code was in fact the right approach, it just didn't put comments about edge cases high enough in the call stack.
I've definitely run into this phenomenon of independently landing on the same design twice because of the same edge cases. At some point back in 2005 or so, I was working on a collision detection component for a physics engine. This was 1-2 years before the Box2D engine, so there was a significant lack of any open source options, so I was rolling my own stuff that was quite similar to Box2D (but Box2D was written much better).
One year later, I came back, looked at the code, thought "this is unreadable!" refactored it, and sure enough, stuff was falling through floors. I went back to my old code, found several comments discussing edge cases having to do with discrete time step problems, and concluded that my old code was in fact the right approach, it just didn't put comments about edge cases high enough in the call stack.
Generalizing even when you are only using your solution once can sometimes be useful.
When you know that certain information should not be used in a correct solution, a more abstract approach can make sure that information stays hidden.
A really simple example: for-loops in Python 'leak' their index variable. Stick that loop inside a local function, and then you know that you can not accidentally make use of the index variable later.
A more complicated example is deliberately coding to an interface that carefully exposes only what should be exposed. Eg using a map or filter higher-order function.
When you know that certain information should not be used in a correct solution, a more abstract approach can make sure that information stays hidden.
A really simple example: for-loops in Python 'leak' their index variable. Stick that loop inside a local function, and then you know that you can not accidentally make use of the index variable later.
A more complicated example is deliberately coding to an interface that carefully exposes only what should be exposed. Eg using a map or filter higher-order function.
As a technique against this, at the point that you're writing the code to begin with, have you ever tried documenting the reasons you're doing something even if it's blatantly obvious at the time?
a lot of people would refactor by seeing if they can put the API call in there, but this wastes massive time you could avoid if you knew the reason for this in the first place. and maybe the API still doesn't have it, and so you put the API call in, you try to remember the reason for the scrape, and then you realize that all this is still the best way to do this, you just have to update the regex to continue to match. work that could have been saved by a simple comment telling you the reason it looks this way.
// rather than use the API we parse a scrape here with a
// regex because we signed up and it doesn't have half the fields we want.
a lot of people would refactor by seeing if they can put the API call in there, but this wastes massive time you could avoid if you knew the reason for this in the first place. and maybe the API still doesn't have it, and so you put the API call in, you try to remember the reason for the scrape, and then you realize that all this is still the best way to do this, you just have to update the regex to continue to match. work that could have been saved by a simple comment telling you the reason it looks this way.
> code that I wrote myself is hard to read
1. Found some extremely cool code, marveled how amazing it works
2. Realized I wrote it as a teenager
3. Got depressed, questioning my life decisions
1. Found some extremely cool code, marveled how amazing it works
2. Realized I wrote it as a teenager
3. Got depressed, questioning my life decisions
The best feeling for me is when I come across old code and then re-write it to make it [simpler | faster | clearer | better] .. It is tangible proof to me that I have improved in my craft.
I usually do this same thing. But not before mentally cursing out the programmer that wrote this poorly documented spaghetti code... After which I realize it was me.
Even well factored code looks like spaghetti at a casual read in a lot of frameworks/cases, and makes sense once you've swapped all that info back in.
>but with better comments
Communication, especially with your future self, is an important skill.
Communication, especially with your future self, is an important skill.
Code twice: once to understand, once to solve.
As in "42", the first bit is more difficult.
As in "42", the first bit is more difficult.
And each time this happens, you get better about writing readable comments up front describing edge cases and difficulties so that future self can avoid steps 1 - 6 with a head start on refactor ideas / feasibility.
> git reset --hard HEAD
story of my life
story of my life
> git stash # i might need this one day
And i never need it.
I've started saving my stashes to branches instead.. adding a _ on the front of the branch name to remind me to delete the branch at some point
Out of curiosity, do you ever actually delete the branches? I would absolutely just end up with a number of _-prefixed branches on all my projects.
I don't allow myself to have more than 1 active stash at any given point on a project. You quickly learn to delete with no regret some code you wrote !
Better than the other way round.
> Re-realize the edge-cases and difficulties
I think comments can help avoid such scenarios.
I think comments can help avoid such scenarios.
This isn't quite the same situation but it reminds me a little bit of xkcd.com/1421
Oh this is such a good comment!
> Legacy code that I wrote myself is hard to read.
Sometimes I don’t even recognize me as the author for a while. Realizing I’m reading something I wrote and can’t understand it without studying carefully has been rather surprising and reminds me of the old Kernighan quote “Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?”
My goals used to be to write code that looked and felt cool to myself and others, to add features in clever ways with as little change to the function signatures and structure as possible so as to not disturb the architecture. While keeping changes small is a good goal to balance, it’s always possible to be too small and add unnamed concepts and fail to restructure around new concepts when you should. Do that a few times in a row (which I have done) and you end up with architectural spaghetti code that might look clean and modular at first glance but becomes a maintenance nightmare. My goals are now to: - make code so easy to read it’s boring, because if it looks interesting, it’s probably too clever - and to identify and name all the unnamed concepts and refactor often to accommodate new features.
> Legacy code that I wrote myself is hard to read.
Sometimes I don’t even recognize me as the author for a while. Realizing I’m reading something I wrote and can’t understand it without studying carefully has been rather surprising and reminds me of the old Kernighan quote “Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?”
My goals used to be to write code that looked and felt cool to myself and others, to add features in clever ways with as little change to the function signatures and structure as possible so as to not disturb the architecture. While keeping changes small is a good goal to balance, it’s always possible to be too small and add unnamed concepts and fail to restructure around new concepts when you should. Do that a few times in a row (which I have done) and you end up with architectural spaghetti code that might look clean and modular at first glance but becomes a maintenance nightmare. My goals are now to: - make code so easy to read it’s boring, because if it looks interesting, it’s probably too clever - and to identify and name all the unnamed concepts and refactor often to accommodate new features.
> the old Kernighan quote “Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?”
This quote can be interpreted in an intelligence-positive way, to encourage you to learn by writing the cleverest possible code. Then, when you get to debug it, you will be forced to improve your skills. This interpretation is called Kernighan's lever [1] and it is very beautiful. The alternative is a life of boredom where you don't learn anything new.
[1] https://www.linusakesson.net/programming/kernighans-lever/in...
This quote can be interpreted in an intelligence-positive way, to encourage you to learn by writing the cleverest possible code. Then, when you get to debug it, you will be forced to improve your skills. This interpretation is called Kernighan's lever [1] and it is very beautiful. The alternative is a life of boredom where you don't learn anything new.
[1] https://www.linusakesson.net/programming/kernighans-lever/in...
”Prod is on fire and nobody can figure out your burrito pasta”
”Isn’t this a wonderful learning opportunity for all of us”
Debugging time is never a good time to start honing new skills.
”Isn’t this a wonderful learning opportunity for all of us”
Debugging time is never a good time to start honing new skills.
“Burrito pasta” is a great term! Is that something that you just came up with?
It sounds like spaghetti code but even worse because it’s covered with a messy layer of beans and guacamole and wrapped in layers of tortilla.
It sounds like spaghetti code but even worse because it’s covered with a messy layer of beans and guacamole and wrapped in layers of tortilla.
Just came up with it. The complexity of monads and other post-grad level CS stuff mixed with good old spaghetti code.
Next up: some doofus who learned high-order Haskell in middle school, and takes offense of me calling it complicated.
PS: https://blog.plover.com/prog/burritos.html
Next up: some doofus who learned high-order Haskell in middle school, and takes offense of me calling it complicated.
PS: https://blog.plover.com/prog/burritos.html
Of course, Kernighan's lever is most useful on individual projects. In an industrial context there are often other constraints. Nobody is saying that you have to always write the most clever code you can. But if you never do it, you will improve your skills very slowly, if at all.
Writing simple code is difficult, more difficult than writing clever code, and is a better skill to grow.
I would hope at least most of the debugging happened before the code made it to production.
I was just pondering this very issue. I think one of the reasons some teams end up with spaghetti code is because the developers are smart enough that they always muddle through it in the end. So when it comes to talking about technical debt, there's never a "it's too complicated," there's just "you're not trying hard enough." In that sense, it would help if the developers had a lower pain tolerance, because it would drive us to actually work hard to improve the ergonomics of our architectures.
> The alternative is a life of boredom where you don't learn anything new.
Now that's an impressive logical leap.
Now that's an impressive logical leap.
False dichotomy, anyone? I learn more from trying new ideas than debugging complex code.
I mean
When I try something new, usually what I learn is not that my assumptions were correct, but the more interesting part is where my assumptions were wrong. This usually only becomes apparent either when writing the code, or in some of the more interesting cases, when debugging.
When I try something new, usually what I learn is not that my assumptions were correct, but the more interesting part is where my assumptions were wrong. This usually only becomes apparent either when writing the code, or in some of the more interesting cases, when debugging.
This quote can be interpreted in an intelligence-positive way, to encourage you to learn by writing the cleverest possible code.
I would claim that any clever final result can be accomplished without any need for intermediate cleverness. Things that look clever to other people but are intuitive to you might be OK. Things that look clever to you should be avoided when possible.
I would claim that any clever final result can be accomplished without any need for intermediate cleverness. Things that look clever to other people but are intuitive to you might be OK. Things that look clever to you should be avoided when possible.
That is absolutely horrific.
I don't want to spend my energy learning the special skills needed to deal with things I should have been smart enough to prevent from ever existing.
When seniors (and above) complain about the low quality of junior code, I tell them to go look at their own code from 6 months ago.
It's an endemic issue, core to the problem of poor software.
> My goals used to be to write code that looked and felt cool to myself and others, ... My goals are now to: - make code so easy to read it’s boring
Same for me, and I'm sure same to many of the folks that have advanced past senior level. The problem of other people, other senior people, needing to read, understand, and significantly modify your code is one of the reasons why you can't really advance past senior in a startup. There aren't enough experienced folks that you have to write "up to". Of course the other part of being post-senior is the ability to scale your expertise, but now I'm digressing quite far. Then once you're that advanced, you don't want to take a pay and scope cut to work at a startup. This is a major contributor to startup technical debt accumulation, one that can't readily be solved.
I still do write "cool code", for code that I will only use myself that doesn't go into production. But for all others, I write easy-to-read code. And I review code with that in mind. When comments have a typo that alter the meaning of the comment, I insist that be fixed. Juniors hate me for being too picky. (and I hate them for being too sloppy.)
Remember, the most important part of your job as senior+ is not what you do yourself, it's how you guide others.
It's an endemic issue, core to the problem of poor software.
> My goals used to be to write code that looked and felt cool to myself and others, ... My goals are now to: - make code so easy to read it’s boring
Same for me, and I'm sure same to many of the folks that have advanced past senior level. The problem of other people, other senior people, needing to read, understand, and significantly modify your code is one of the reasons why you can't really advance past senior in a startup. There aren't enough experienced folks that you have to write "up to". Of course the other part of being post-senior is the ability to scale your expertise, but now I'm digressing quite far. Then once you're that advanced, you don't want to take a pay and scope cut to work at a startup. This is a major contributor to startup technical debt accumulation, one that can't readily be solved.
I still do write "cool code", for code that I will only use myself that doesn't go into production. But for all others, I write easy-to-read code. And I review code with that in mind. When comments have a typo that alter the meaning of the comment, I insist that be fixed. Juniors hate me for being too picky. (and I hate them for being too sloppy.)
Remember, the most important part of your job as senior+ is not what you do yourself, it's how you guide others.
> seniors [...] complain about the low quality of junior code [...] their own code from 6 months ago.
What classes as 'senior' that their own coding style has changed that much in 6 months? O.o
> I still do write "cool code", for code that I will only use myself that doesn't go into production. But for all others, I write easy-to-read code.
Good dev. Remember, you are not your audience. Unless you're just writing play-code in which case go nuts and be as 'clever' as you want. :D
> When comments have a typo that alter the meaning of the comment, I insist that be fixed. Juniors hate me for being too picky.
Then they're wrong, and tbh that's not something I'd accept more than once from an employee.
What classes as 'senior' that their own coding style has changed that much in 6 months? O.o
> I still do write "cool code", for code that I will only use myself that doesn't go into production. But for all others, I write easy-to-read code.
Good dev. Remember, you are not your audience. Unless you're just writing play-code in which case go nuts and be as 'clever' as you want. :D
> When comments have a typo that alter the meaning of the comment, I insist that be fixed. Juniors hate me for being too picky.
Then they're wrong, and tbh that's not something I'd accept more than once from an employee.
> > seniors [...] complain about the low quality of junior code [...] their own code from 6 months ago.
> What classes as 'senior' that their own coding style has changed that much in 6 months? O.o
Your code style can remain exactly the same, and it would still happen. The reason is not that you would write the code differently today, but that you forgot the issues and edge cases that made you write it like that then, and that at the time you focused too much on the writing, not on the reading.
> What classes as 'senior' that their own coding style has changed that much in 6 months? O.o
Your code style can remain exactly the same, and it would still happen. The reason is not that you would write the code differently today, but that you forgot the issues and edge cases that made you write it like that then, and that at the time you focused too much on the writing, not on the reading.
Here we get to the real heart of the problem. Engineers of all levels seem to default into “this code is shit - I could do better” instead of having some empathy and considering they don’t have the whole picture.
But the wrong lesson seems to be taken away from this. It’s not that all code is shit - it’s that you aren’t good at reading the code yet if you can’t see all the little hairs and bug fixes.
But the wrong lesson seems to be taken away from this. It’s not that all code is shit - it’s that you aren’t good at reading the code yet if you can’t see all the little hairs and bug fixes.
> Engineers of all levels seem to default into “this code is shit - I could do better” instead of having some empathy and considering they don’t have the whole picture.
several projects I've come in to - yeah, the code what shit, and yeah, I could do better. And I've done better. By asking questions, documenting the answers, writing sample data, and writing tests.
I get that code can be sloppy, have edge cases, etc. Took over a project that was halfway migrated from CI to Laravel. The migrator had close to a year on this 'migration'. We had not one unit test case, no migrations, no seeders, no integration tests when we took over. What we had was piles of half-baked uncommented model code, over-reliance on magic methods, Laravel/CI models with the same names and method names often being used in the same request but with unintentionally dissimilar behavior.
The 'code' isn't the (whole) problem. All the other stuff around the code that provides the context is the problem. We had ~ 20 tickets in a tracking system with vague notes, and were given 5 email threads of discussion about functionality questions, none with actual resolution.
> it’s that you aren’t good at reading the code yet if you can’t see all the little hairs and bug fixes.
Or... the person writing it before you simply didn't know how to write/document.
Sometimes - really, honestly - you can actually "do it better" because... really, honestly, sometimes you are actually better - more competent, more experienced, more diligent, more professional - than the person who left the code you're working on. Not always, but not never.
several projects I've come in to - yeah, the code what shit, and yeah, I could do better. And I've done better. By asking questions, documenting the answers, writing sample data, and writing tests.
I get that code can be sloppy, have edge cases, etc. Took over a project that was halfway migrated from CI to Laravel. The migrator had close to a year on this 'migration'. We had not one unit test case, no migrations, no seeders, no integration tests when we took over. What we had was piles of half-baked uncommented model code, over-reliance on magic methods, Laravel/CI models with the same names and method names often being used in the same request but with unintentionally dissimilar behavior.
The 'code' isn't the (whole) problem. All the other stuff around the code that provides the context is the problem. We had ~ 20 tickets in a tracking system with vague notes, and were given 5 email threads of discussion about functionality questions, none with actual resolution.
> it’s that you aren’t good at reading the code yet if you can’t see all the little hairs and bug fixes.
Or... the person writing it before you simply didn't know how to write/document.
Sometimes - really, honestly - you can actually "do it better" because... really, honestly, sometimes you are actually better - more competent, more experienced, more diligent, more professional - than the person who left the code you're working on. Not always, but not never.
Oh absolutely code can be shit. But I’ve also seen code that’s made the company millions of dollars and run flawlessly for 20 years be called “shit” because it doesn’t look like modern code. The replacement naturally consumes many times more resources and has bugs that were long fixed in the old code.
In my experience the latter case is far more common. But I suppose experiences will differ dramatically depending on what you work on.
In my experience the latter case is far more common. But I suppose experiences will differ dramatically depending on what you work on.
I'd meant to add that part as well too - code can be bad and still work, and work OK. The problems only come in when it needs to be changed.
I've advised a number of folks to care less about the code style, and focus more on making it at least understandable. I don't particularly care if you're using a factory pattern or not, but please do doc/comment someplace what the expected behavior for your 'backordering' logic is. I can fix things later if I understand what was intended, vs just what I have to guess at later.
Have worked on some projects in the last few years that are 'bad' from code perspective. One is bad, but the company as a whole operates... decently, and is improving, and more importantly, is providing a lot of value to their customers. The customers tolerate some bugs now and then because a) they still get value and b) the issues are addressed. There's a full process for changes/fixes/rollouts, and the team overall understands that there's tech debt to deal with. Some folks understand that they're still paying off tech debt from 3-4 years ago, and understand those decisions were bad, and try to avoid those same mistakes.
Hundreds of integration and unit tests (growing every week) help grow the confidence levels, and remove barriers to smaller refactoring efforts, because there's a reasonable way to detect the impact of changes. It's not perfect, but that's also understood and accepted.
Another one is the CI/Laravel situation from above. Small company, no real 'tech' people on staff - it's all 'outsourced'. They're frustrated because they see other companies progressing faster than they do, and everything seems to take 5x longer than they expect. It's because the code is bad (on many levels). If we were not trying to make any changes, and it just ran in its current state, it would still continue to make money for them, but they want new features, which requires actually understanding how everything fits together. It took two people several months to have a reasonable understanding of how all the running parts fit together (while also trying to add new features/etc), and finally get a small number of unit tests in place.
I've advised a number of folks to care less about the code style, and focus more on making it at least understandable. I don't particularly care if you're using a factory pattern or not, but please do doc/comment someplace what the expected behavior for your 'backordering' logic is. I can fix things later if I understand what was intended, vs just what I have to guess at later.
Have worked on some projects in the last few years that are 'bad' from code perspective. One is bad, but the company as a whole operates... decently, and is improving, and more importantly, is providing a lot of value to their customers. The customers tolerate some bugs now and then because a) they still get value and b) the issues are addressed. There's a full process for changes/fixes/rollouts, and the team overall understands that there's tech debt to deal with. Some folks understand that they're still paying off tech debt from 3-4 years ago, and understand those decisions were bad, and try to avoid those same mistakes.
Hundreds of integration and unit tests (growing every week) help grow the confidence levels, and remove barriers to smaller refactoring efforts, because there's a reasonable way to detect the impact of changes. It's not perfect, but that's also understood and accepted.
Another one is the CI/Laravel situation from above. Small company, no real 'tech' people on staff - it's all 'outsourced'. They're frustrated because they see other companies progressing faster than they do, and everything seems to take 5x longer than they expect. It's because the code is bad (on many levels). If we were not trying to make any changes, and it just ran in its current state, it would still continue to make money for them, but they want new features, which requires actually understanding how everything fits together. It took two people several months to have a reasonable understanding of how all the running parts fit together (while also trying to add new features/etc), and finally get a small number of unit tests in place.
...you don't remember what you were doing 6 months ago? I'm sorry, that's still not a good excuse. Maybe you don't remember every tiny facet but hopefully you'd have a general idea. And above all that, if you're a senior dev then you'd understand that "this code is unfamiliar" does NOT mean "this code is bad."
I mean really, "this code is unfamiliar therefore it's messy therefore we should rewrite it" is a flaming red flag. Chesterton's fence, people!
I mean really, "this code is unfamiliar therefore it's messy therefore we should rewrite it" is a flaming red flag. Chesterton's fence, people!
One of my favorite things about comments in programming is that you can stick a label on that fence explaining why it's there. One of my biggest frustrations is that so many people don't bother, even when it would literally be just one little sentence.
> One of my favorite things about comments in programming is that you can stick a label on that fence explaining why it's there.
This is routine for ordinary cultural practices as well. However, the common explanation for a given cultural practice usually has nothing to do with the actual reasons it might be a good idea.
This is routine for ordinary cultural practices as well. However, the common explanation for a given cultural practice usually has nothing to do with the actual reasons it might be a good idea.
Unknown unknowns.
My coding style hasn't really changed in years - frankly, I don't write a lot of code, I do other things. But I often run into situations where I'm irritated at my own bad code from months earlier, when the shortcomings of the code are actually driven by things I know now that I didn't know then.
My coding style hasn't really changed in years - frankly, I don't write a lot of code, I do other things. But I often run into situations where I'm irritated at my own bad code from months earlier, when the shortcomings of the code are actually driven by things I know now that I didn't know then.
Review process surely mitigates differences between "junior" and "senior" code?
This also would require that devs who are on the PR reviews ACTUALLY look at the code. In about every job I've worked at in my short career there are people I work with that I don't trust them to actually review my code. I've come to accept that. I instead make sure the people I know will do a decent job are on the PR. Some people will just look at the diff and an even smaller few will actually pull the branch locally so they can see the entire context. That being said I always do my best to review other peoples code regardless of whether or not they will review mine.
Not really. It just ensures no really atrocious code makes it into master.
Of course you can stall any junior merge request until it looks like senior code, but at that point you might as well write it yourself.
Of course you can stall any junior merge request until it looks like senior code, but at that point you might as well write it yourself.
I don't know if it's stalling so much as taking the time to request changes / pair up and teach.
If bad code is getting merged, that's tech debt / time someone else is going to have to spend anyway, plus the time needed to identify the issue and triage down the line. I would think it's better investment to use that time up front and help the jumior level up too.
If bad code is getting merged, that's tech debt / time someone else is going to have to spend anyway, plus the time needed to identify the issue and triage down the line. I would think it's better investment to use that time up front and help the jumior level up too.
> Sometimes I don’t even recognize me as the author for a while.
This happened to me just yesterday! I was helping a co-worker with a problem, and I noticed some redundant code in the same function, so I told him he could simplify it while he was there. His response was, "...but you wrote that". (And as it turns out, only a few days prior!)
This happened to me just yesterday! I was helping a co-worker with a problem, and I noticed some redundant code in the same function, so I told him he could simplify it while he was there. His response was, "...but you wrote that". (And as it turns out, only a few days prior!)
This is why I will point out issues in code only on the form of stating potential improvements as best as I can. I especially try to avoid hating on the author - it might have been me or the boss who's standing nearby...
In fact, I often conciously refrain from using blame on an "interesting" piece of code because it doesn't matter who wrote it. Looking it up would just satisfy idle curiosity, but yield noninsight into how to improve the code. In fact, I think that blame should just list the commits, but hide the authors by default. "What changed? " and "how?" are always much more pressing questions than "who?".
In fact, I often conciously refrain from using blame on an "interesting" piece of code because it doesn't matter who wrote it. Looking it up would just satisfy idle curiosity, but yield noninsight into how to improve the code. In fact, I think that blame should just list the commits, but hide the authors by default. "What changed? " and "how?" are always much more pressing questions than "who?".
My experience varies a lot. Maybe it's just my colleagues write better commit messages but blame (and looking up the PR and code review) is often a good method of understanding why the code is that way
Yes, but blame puts the focus too much on the authors instead of the changes themselves. I also use it to understand how code evolved over time, but only in circumstances where I suspect the history to hold import clues.
Pinning bad work on a person does not make progress. Fixing bad code does.
Pinning bad work on a person does not make progress. Fixing bad code does.
I am coming back from vacations next week and have 2 PRs to finish (couldn’t merge before because they are high risk), I am antecipating a lot of pain just to pick them up where I left off... I would rather do my tax returns instead lol
It always happens to me while I approve my own pull requests to master.. :’(
> Understood as senior: If a junior programmer tells me they found a system-level bug, I won't believe them and will tell them to go figure out what's wrong with their code.
My first job was in finance and I remember one time that I had a glitch on a complicated Excel spreadsheet. I checked it over, checked again and checked again until I finally concluded that the bug was in Excel itself. So I go to my boss and tell him that the data isn't ready because there's a bug in Excel. I was laughed at by the entire team. They agreed to give me $1000 right then and there if it was really a bug, but if not, I had to admit the shame. Well... of course it wasn't a bug in Excel, I just made a careless, albeit hard-to-find, mistake.
Lesson learned. If millions of people use something, that doesn't mean it doesn't have bugs. But it does mean that you probably aren't going to find those bugs unless you are doing something strange.
oddly, I did once find an actual bug with indexes in Postgres. Because of my earlier experience, I spent a lot of time assuming it was me before I finally isolated it as being a bug with postgres itself. I submitted a bug report and it was patched within a day. But still, 99% of the time, it's me.
My first job was in finance and I remember one time that I had a glitch on a complicated Excel spreadsheet. I checked it over, checked again and checked again until I finally concluded that the bug was in Excel itself. So I go to my boss and tell him that the data isn't ready because there's a bug in Excel. I was laughed at by the entire team. They agreed to give me $1000 right then and there if it was really a bug, but if not, I had to admit the shame. Well... of course it wasn't a bug in Excel, I just made a careless, albeit hard-to-find, mistake.
Lesson learned. If millions of people use something, that doesn't mean it doesn't have bugs. But it does mean that you probably aren't going to find those bugs unless you are doing something strange.
oddly, I did once find an actual bug with indexes in Postgres. Because of my earlier experience, I spent a lot of time assuming it was me before I finally isolated it as being a bug with postgres itself. I submitted a bug report and it was patched within a day. But still, 99% of the time, it's me.
It's unusual, but it does happen. My example is actually from hardware.
I was writing a Windows NT (what's that?) device driver for a communications board we developed for one of our products. I kept running into a problem and struggled with it for days. I was experienced enough to understand that the error was probably mine and the problem was so basic that if it was in the chip pretty much everyone who tried to use it in that mode would be screaming about it not working. The chip was an 8-channel UART (serial converter) and IIRC, the bug was in one of the FIFO interrupt modes.
Finally I gave up, got the phone number for the chip vendor's (I think it was Texas Instruments) local Field Applications Engineer and explained the problem to him. "Oh, yeah, we know about that bug, there's a new version of the chip about to be released. You guys are actually only the second customer to sample that chip. Lucky we found the problem before it went into production!"
I was writing a Windows NT (what's that?) device driver for a communications board we developed for one of our products. I kept running into a problem and struggled with it for days. I was experienced enough to understand that the error was probably mine and the problem was so basic that if it was in the chip pretty much everyone who tried to use it in that mode would be screaming about it not working. The chip was an 8-channel UART (serial converter) and IIRC, the bug was in one of the FIFO interrupt modes.
Finally I gave up, got the phone number for the chip vendor's (I think it was Texas Instruments) local Field Applications Engineer and explained the problem to him. "Oh, yeah, we know about that bug, there's a new version of the chip about to be released. You guys are actually only the second customer to sample that chip. Lucky we found the problem before it went into production!"
Junior programmers find an amazing amount of system-level issues.
One noob came to me with a serious codegen bug in GCC, where even with `-O0` it would fail to correctly run a trivial for loop. Another found a huge security hole in `sudo` that gave everyone unrestricted access. My favorite was one who asked if the JDK standard library had any known bugs processing the letter "g".
They all turned out to be user error, if you can believe it.
One noob came to me with a serious codegen bug in GCC, where even with `-O0` it would fail to correctly run a trivial for loop. Another found a huge security hole in `sudo` that gave everyone unrestricted access. My favorite was one who asked if the JDK standard library had any known bugs processing the letter "g".
They all turned out to be user error, if you can believe it.
There was a junior in one of the early companies I worked at who claimed to have found a JVM bug. He insisted JVM handled comparison with null incorrectly. He had a String variable that was null, then he guarded against NPE with "if (str == null) return -1" followed by code that dereferenced str. The code looked innocent at first glance, but somehow it failed with NPE. Finally it turned out the string was "null" not null. :D
But I also have a good counter-example story:
Some day I found an HTTP rfc violation in one of very popular oss HTTP client libraries. I filed a bug report with detailed reproduction. It was closed immediately, with "works as designed, you misunderstood HTTP". Then we had a debate in ticket comments for many days and I couldn't convince them to the right interpretation of HTTP (I admit, the text is not easy sometimes). Finally I posted a message on HTTP mailing list and Roy Fielding confirmed I was right. They reopened and fixed. I must say this is really hard thing to argue with somebody with an edge in experience and not come out as arrogant.
In particular - when somebody responds with "I have more experience / I've been doing it for 20 years, and you say I'm wrong?". How to best handle such cases?
But I also have a good counter-example story:
Some day I found an HTTP rfc violation in one of very popular oss HTTP client libraries. I filed a bug report with detailed reproduction. It was closed immediately, with "works as designed, you misunderstood HTTP". Then we had a debate in ticket comments for many days and I couldn't convince them to the right interpretation of HTTP (I admit, the text is not easy sometimes). Finally I posted a message on HTTP mailing list and Roy Fielding confirmed I was right. They reopened and fixed. I must say this is really hard thing to argue with somebody with an edge in experience and not come out as arrogant.
In particular - when somebody responds with "I have more experience / I've been doing it for 20 years, and you say I'm wrong?". How to best handle such cases?
>"I've been doing it for 20 years, and you say I'm wrong?" How to best handle such cases?
I wish I knew. I try to limit the discussion to the purely technical, or to barely acknowledge it as in "sure, but RFC123 says X and Y implements it that way as shown in Z".
Of course, that goes for when I'm the authority as well. I don't care who is correct, I care about what.
I wish I knew. I try to limit the discussion to the purely technical, or to barely acknowledge it as in "sure, but RFC123 says X and Y implements it that way as shown in Z".
Of course, that goes for when I'm the authority as well. I don't care who is correct, I care about what.
Haha, that last one is hilarious!
Even though I'm still juniorish, I still run into issues like this that stump me. But then occasionally you do find bugs with existing software which keeps you second guessing everything. Usually those bugs come from using two things in conjunction that haven't been well tested together.
Also sometimes, you find a bug that isn't accepted by the software vendor/owning team as a bug, because it has some sort of obscure work around that would take you a week of tinkering to figure out. Those "aren't bugs" but yeah, they are bugs. Software vendors that also sell consulting and related services love to pull shit like that
Even though I'm still juniorish, I still run into issues like this that stump me. But then occasionally you do find bugs with existing software which keeps you second guessing everything. Usually those bugs come from using two things in conjunction that haven't been well tested together.
Also sometimes, you find a bug that isn't accepted by the software vendor/owning team as a bug, because it has some sort of obscure work around that would take you a week of tinkering to figure out. Those "aren't bugs" but yeah, they are bugs. Software vendors that also sell consulting and related services love to pull shit like that
I actually found an OS bug in AIX on my first real I-designed-this code project. Worse, the bug was discovered only when the code went into production - it behaved differently on the test servers than on the production servers! The bug caused mmap() system calls to randomly overwrite certain pages in memory with NULLs. Yeah, that was fun. And it was caused by the order in which patches had been applied, which was why it behaved differently in production than in dev/test.
If some second year programmer told me that nonsense, I'd make them go back and either find their bug, or write a test program that exercised the bug in isolation (which was what I did).
If some second year programmer told me that nonsense, I'd make them go back and either find their bug, or write a test program that exercised the bug in isolation (which was what I did).
[deleted]
Were you finally believed?
Eventually. I had to write a test program, as small and neat as possible, that demonstrated the problem on both test and prod systems. Then I got permission to send it to IBM (with my binary, my source code, and my logs). They eventually determined it was caused by the order patches had been applied on the servers - they had the same patches, just applied in a different order.
I just say, even if it's a bug, there's no guarantee it'll be fixed on a timeline that's agreeable to our deadlines. Find a workaround.
> Understood as senior: Legacy code that I wrote myself is hard to read.
For me, any code that I wrote more than 3 weeks, I forgot. That's why I comment the hell out of my code. The younger programmers have routinely told me "commented code means the code isn't very good." I chuckle and ignore them and wait for them to hit their mid-30s and older.
For me, any code that I wrote more than 3 weeks, I forgot. That's why I comment the hell out of my code. The younger programmers have routinely told me "commented code means the code isn't very good." I chuckle and ignore them and wait for them to hit their mid-30s and older.
Also related:
> Understood as senior: Communication skills matter most.
The reason people dismiss comments is usually that they or others around them aren't good at writing useful comments.
Especially when there are linter rules requiring comments you'll have something like def open_thing(x, y): and a comment, "defines a function that opens thing."
Yes, those are pointless. Often what's going on is a person is dumping their stream of consciousness into the comment field.
It takes practice to understand what a reader needs to know. You have to actually practice reading comments and thinking things through (another reason code review is important in your team) to get good at undertanding what you should write down.
All that said, if you truly hate commenting, at least build a habit of descriptive naming and exploiting your type system as fully as possible.
> Understood as senior: Communication skills matter most.
The reason people dismiss comments is usually that they or others around them aren't good at writing useful comments.
Especially when there are linter rules requiring comments you'll have something like def open_thing(x, y): and a comment, "defines a function that opens thing."
Yes, those are pointless. Often what's going on is a person is dumping their stream of consciousness into the comment field.
It takes practice to understand what a reader needs to know. You have to actually practice reading comments and thinking things through (another reason code review is important in your team) to get good at undertanding what you should write down.
All that said, if you truly hate commenting, at least build a habit of descriptive naming and exploiting your type system as fully as possible.
I'm actually thinking more of social skills and written language, not programming. I said something about this in a different thread earlier this week, and someone was baffled as to why I thought being able to write and sell was important, since you just wind up doing what your boss tells you to do anyway.
As opposed to telling the boss what you're going to do.
As opposed to telling the boss what you're going to do.
> Especially when there are linter rules requiring comments you'll have something like def open_thing(x, y): and a comment, "defines a function that opens thing."
I actually think those comments are useful in two ways:
1. The process of writing a comment will help often help me rename the function/variables so e.g. “defines a function that opens thing” becomes something like “opens can_of_worms with the given instrument and restraints” for the method definition open_can_of_worms(instrument, restraints)
2. You can use variable/return value comments to further restrict the domain of values, e.g. non-null, positive or in the range 1-42 (arguably it would be better to express some of these in the type system, but that is a different discussion). These comments show up in my IDE when I try to call the code in a remote location, so I don’t have to guess or remember the constraints.
(edit formatting)
I actually think those comments are useful in two ways:
1. The process of writing a comment will help often help me rename the function/variables so e.g. “defines a function that opens thing” becomes something like “opens can_of_worms with the given instrument and restraints” for the method definition open_can_of_worms(instrument, restraints)
2. You can use variable/return value comments to further restrict the domain of values, e.g. non-null, positive or in the range 1-42 (arguably it would be better to express some of these in the type system, but that is a different discussion). These comments show up in my IDE when I try to call the code in a remote location, so I don’t have to guess or remember the constraints.
(edit formatting)
Comments rot, and details about what is going on is better incorporated using good variable names and functions that abstract aspects of a task from their implementation.
While I don't like comments that try to explain what code is doing (write better code), comments are very useful for annotating WHY code does what it does. They're also very useful for adding documentation references, code use gotchas and things that need to be addressed in the future.
While I don't like comments that try to explain what code is doing (write better code), comments are very useful for annotating WHY code does what it does. They're also very useful for adding documentation references, code use gotchas and things that need to be addressed in the future.
Comments are critical for explaining the code that isn’t there. False starts, obvious optimizations that don’t actually work, etc.
I've heard these sentiments very frequently from junior programmers, and almost never from senior programmers.
I'm guessing most of the senior programmers you've interacted with are maintaining established software with low churn and high availability requirements.
I hear comment love very frequently from enterprise engineers working with 10+ year old Java codebases, but very infrequently from hackers working with young code bases in more concise languages (complex algorithms aside).
I hear comment love very frequently from enterprise engineers working with 10+ year old Java codebases, but very infrequently from hackers working with young code bases in more concise languages (complex algorithms aside).
Complete opposite for me.
I think it's better to document the context/intention/business reasons and let the code speak for itself.
This assumes everybody reading the code at the company have the skill to read it.
Where I work, I can expect my scalacode to be read by people who can barely write a line of it, and I routinely read typescript and go code while being totally inept at those.
I bless comments that are here to help the reader read, and I let those behind too where there's some specialists-only syntax.
Where I work, I can expect my scalacode to be read by people who can barely write a line of it, and I routinely read typescript and go code while being totally inept at those.
I bless comments that are here to help the reader read, and I let those behind too where there's some specialists-only syntax.
[deleted]
Early 30s here and I've realised that comments are worse than useless most of the time. Nothing enforces that the comment is correct, so a significant proportion of comments will be false, so no comments can be relied upon.
Descriptive types, clear tests, and sensible variable names are much more effective strategies for making code understandable. Comments should be a last-resort stopgap.
Descriptive types, clear tests, and sensible variable names are much more effective strategies for making code understandable. Comments should be a last-resort stopgap.
Honestly, I would add this whole comment to the list of "absolute truths" juniors unlearn as they get more experience. And I would also point to the original post's point that types of experience matter - just because you're early 30s doesn't necessary mean you've had the right experience. If you still believe this, then - to be brutally honest - I would question the quality of the teams you've worked with.
Comments don't have to decay. Discipline is important. Culture is important. And yes, these have to be intentionally set and upheld.
If you set a culture of discipline around maintaining the comments with the code, and ensuring they are updated, then it's really not that hard to do it. If the developer doesn't remember to do it when making changes, then the code reviewer can catch it and enforce it.
And nothing really substitutes for an english language explanation of the "why" and the intention of a particular section of code. A good comment explaining why something was done a particular way, or what the code was intended to accomplish, can save hours of walking up and down call stacks. It's also something that cannot be communicated through unit tests, or even integration tests, a lot of the time. Those communicate the "what" and the "how" - not the "why".
Comments don't have to decay. Discipline is important. Culture is important. And yes, these have to be intentionally set and upheld.
If you set a culture of discipline around maintaining the comments with the code, and ensuring they are updated, then it's really not that hard to do it. If the developer doesn't remember to do it when making changes, then the code reviewer can catch it and enforce it.
And nothing really substitutes for an english language explanation of the "why" and the intention of a particular section of code. A good comment explaining why something was done a particular way, or what the code was intended to accomplish, can save hours of walking up and down call stacks. It's also something that cannot be communicated through unit tests, or even integration tests, a lot of the time. Those communicate the "what" and the "how" - not the "why".
> Comments don't have to decay. Discipline is important. Culture is important. And yes, these have to be intentionally set and upheld.
These are things that are often completely outside your control.
> If you set a culture...
At most shops, you don't get to set the culture. About the only time you do is if you're a founder or early developer. Otherwise you have to fit into the existing culture, or attempt to find a company that better reflects what you want. Sure, it's not hopeless; you can likely influence to some extent, but your influence is usually limited.
> And nothing really substitutes for an english language explanation of the "why" and the intention of a particular section of code.
I do agree with this. Any code that can't be written in a self-documenting way absolutely must be commented. However, if you find the need to do this often, it might be a sign that you should focus more on code clarity and less on (likely premature) optimization, or perhaps consider if you're really using the right tool (language, framework, etc.) for the job at hand.
I will admit that I probably comment less than I should, but I feel like the average is way too verbose, and that enough comments are out of date and incorrect (often in very subtle ways) that it adds significantly to my overhead when trying to understand someone else's (or even my own) code.
These are things that are often completely outside your control.
> If you set a culture...
At most shops, you don't get to set the culture. About the only time you do is if you're a founder or early developer. Otherwise you have to fit into the existing culture, or attempt to find a company that better reflects what you want. Sure, it's not hopeless; you can likely influence to some extent, but your influence is usually limited.
> And nothing really substitutes for an english language explanation of the "why" and the intention of a particular section of code.
I do agree with this. Any code that can't be written in a self-documenting way absolutely must be commented. However, if you find the need to do this often, it might be a sign that you should focus more on code clarity and less on (likely premature) optimization, or perhaps consider if you're really using the right tool (language, framework, etc.) for the job at hand.
I will admit that I probably comment less than I should, but I feel like the average is way too verbose, and that enough comments are out of date and incorrect (often in very subtle ways) that it adds significantly to my overhead when trying to understand someone else's (or even my own) code.
> If you still believe this, then - to be brutally honest - I would question the quality of the team's you've worked with.
To be equally brutally honest: right back at you. I would trust the quality of those I've worked with over those who believe in comments, any day of the week.
My point was simply that I started as a believer in comments when I was more junior, and became anti-comment through experience. So even if we believe senior people are more likely to be right than junior people (which I very much doubt, frankly), that tells us little about whether comments are good or not.
> If you set a culture of discipline around maintaining the comments with the code, and ensuring they are updated, then it's really not that hard to do it.
Human programmers have a limited discipline budget, and if you're spending it on keeping the comments up to date then you're not spending it on other things. Yes, you can use manual effort to keep code explanations up to date, just as you can use manual effort to ensure that you don't use memory after it's freed, or that your code is formatted consistently, or that the tests were run before a PR is merged. But you're better off automating those things and saving your manual effort for the things that can't be automated.
> And nothing really substitutes for an english language explanation of the "why" and the intention of a particular section of code.
Disagree; code can be much more precise and clear than English, that's its great advantage. As the saying goes, the code is for humans to understand, and only incidentally for the computer to execute. The whole point of coding declaratively is that the "why" is front and center and the "what"/"how" follows from that.
To be equally brutally honest: right back at you. I would trust the quality of those I've worked with over those who believe in comments, any day of the week.
My point was simply that I started as a believer in comments when I was more junior, and became anti-comment through experience. So even if we believe senior people are more likely to be right than junior people (which I very much doubt, frankly), that tells us little about whether comments are good or not.
> If you set a culture of discipline around maintaining the comments with the code, and ensuring they are updated, then it's really not that hard to do it.
Human programmers have a limited discipline budget, and if you're spending it on keeping the comments up to date then you're not spending it on other things. Yes, you can use manual effort to keep code explanations up to date, just as you can use manual effort to ensure that you don't use memory after it's freed, or that your code is formatted consistently, or that the tests were run before a PR is merged. But you're better off automating those things and saving your manual effort for the things that can't be automated.
> And nothing really substitutes for an english language explanation of the "why" and the intention of a particular section of code.
Disagree; code can be much more precise and clear than English, that's its great advantage. As the saying goes, the code is for humans to understand, and only incidentally for the computer to execute. The whole point of coding declaratively is that the "why" is front and center and the "what"/"how" follows from that.
> The whole point of coding declaratively is that the "why" is front and center and the "what"/"how" follows from that.
I've been writing Lisp off and on since late last century, so I know full well the value of declarative code. Preaching to the choir, there! But I can also report that every real program I've ever written (i.e., that had at least one user) needed significant non-declarative parts.
And for those non-declarative parts, you need the "why". Why is this call before that one? Why is this system call used? Why is this constant being passed to the call? And so on. (It's because when you run it on OS ${a} version ${b}, there's a bug in the ${c} library that requires us to force the initialization of the ${d} subsystem before it can ... true story.)
The declarative parts of your program don't require "why" comments, and that's great, but a corollary to that is the parts that can be written in a declarative style aren't the ones that require a "why". Building a DOM structure manually takes a lot of lines of code, but it's all still quite simple, and requires no explanation. Writing a trampoline necessitates a bunch of "why"s, and there's no way to just substitute a declaration for it (without pushing the whole mess somewhere else).
Code is first for humans to understand, and that requires comments, because humans speak English (or some other natural language), and no programming language is yet powerful enough to efficiently (in time or space) express everything that English can.
I've been writing Lisp off and on since late last century, so I know full well the value of declarative code. Preaching to the choir, there! But I can also report that every real program I've ever written (i.e., that had at least one user) needed significant non-declarative parts.
And for those non-declarative parts, you need the "why". Why is this call before that one? Why is this system call used? Why is this constant being passed to the call? And so on. (It's because when you run it on OS ${a} version ${b}, there's a bug in the ${c} library that requires us to force the initialization of the ${d} subsystem before it can ... true story.)
The declarative parts of your program don't require "why" comments, and that's great, but a corollary to that is the parts that can be written in a declarative style aren't the ones that require a "why". Building a DOM structure manually takes a lot of lines of code, but it's all still quite simple, and requires no explanation. Writing a trampoline necessitates a bunch of "why"s, and there's no way to just substitute a declaration for it (without pushing the whole mess somewhere else).
Code is first for humans to understand, and that requires comments, because humans speak English (or some other natural language), and no programming language is yet powerful enough to efficiently (in time or space) express everything that English can.
> Writing a trampoline necessitates a bunch of "why"s, and there's no way to just substitute a declaration for it (without pushing the whole mess somewhere else).
I've got a trampoline in my codebase to avoid a stack overflow. The why is the test that a certain repeated operation doesn't stack overflow.
There are a number of places where it could've been implemented with one technique or another, but there's no particular reason that the approach I've taken should be better or worse than one of the other options. If there was, I'd want to formalise that (e.g. if I'd chosen one approach because it performed better than another, I'd want a benchmark test that actually checked that).
I've got a trampoline in my codebase to avoid a stack overflow. The why is the test that a certain repeated operation doesn't stack overflow.
There are a number of places where it could've been implemented with one technique or another, but there's no particular reason that the approach I've taken should be better or worse than one of the other options. If there was, I'd want to formalise that (e.g. if I'd chosen one approach because it performed better than another, I'd want a benchmark test that actually checked that).
> code can be much more precise and clear than English,
This doesn't address the parent's criticism. Clear, precise code only tells you what the computer is doing. What it can never tell you is why the computer needs to do it exactly like that.
Software breaks in weird ways when pushed to the limits. The fixes for these edge cases are not always obvious and may not be something that can be replicated with testing.
Without comments, some cowboy can come along and think, "it's flushing a buffer here? that's dumb. <delete>" The change gets put in, passes testing, spends four months in production, when a bug report comes in from a customer complaining about an issue that they had three years ago.
Now someone has to spend a bunch of time figuring out the problem, QAing the fix, then getting it back into production. It's thousands of dollars that the company could have saved if only there was a comment about why that buffer flush was there.
You might think this is some crazy edge case, but it's not.
This doesn't address the parent's criticism. Clear, precise code only tells you what the computer is doing. What it can never tell you is why the computer needs to do it exactly like that.
Software breaks in weird ways when pushed to the limits. The fixes for these edge cases are not always obvious and may not be something that can be replicated with testing.
Without comments, some cowboy can come along and think, "it's flushing a buffer here? that's dumb. <delete>" The change gets put in, passes testing, spends four months in production, when a bug report comes in from a customer complaining about an issue that they had three years ago.
Now someone has to spend a bunch of time figuring out the problem, QAing the fix, then getting it back into production. It's thousands of dollars that the company could have saved if only there was a comment about why that buffer flush was there.
You might think this is some crazy edge case, but it's not.
This is my problem as with this argument as well. English and other spoken languages seem first and foremost about conveying ideas. Programming languages seem first and foremost about conveying instructions to computers that don't comprehend "ideas"..
Reconstructing the original idea or meaning can often involve far more context than local variable and functioning naming can provide.
Reconstructing the original idea or meaning can often involve far more context than local variable and functioning naming can provide.
I don't understand what sort of environment you work in where you don't encounter situations where comments could add clarity to the code.
Do you never see code that has global side effects? Or that is written a particular way to take advantage of the hardware that it is running on? Or any other of the many ways that the intention and meaning of a piece of code within the codebase it exists in can be not immediately obvious?
Do you never see code that has global side effects? Or that is written a particular way to take advantage of the hardware that it is running on? Or any other of the many ways that the intention and meaning of a piece of code within the codebase it exists in can be not immediately obvious?
>Do you never see code that has global side effects?
The answer for modern languages and frameworks is "write pure functions."
>Or that is written a particular way to take advantage of the hardware that it is running on?
Move to service/helper/utility class for that particular hardware or with a name that clarifies it's for that particular hardware.
I find comments to be necessary very rarely. Atm looking at a codebase where they are made to cover up for a lack of desire to think.
The answer for modern languages and frameworks is "write pure functions."
>Or that is written a particular way to take advantage of the hardware that it is running on?
Move to service/helper/utility class for that particular hardware or with a name that clarifies it's for that particular hardware.
I find comments to be necessary very rarely. Atm looking at a codebase where they are made to cover up for a lack of desire to think.
> The whole point of coding declaratively is that the "why" is front and center and the "what"/"how" follows from that.
Declarative means that we specify the "what", and the machine deduces the "how".
There is no room for "why", because our present-day machines do not require motivating argumentation in order to do our bidding. They either need the "what" or the "how", or whatever blend of the two that we find convenient.
We need the "why" in the documentation. Such as: why is this program written in the first place? The "why" is not in the code. When code is clear, it's just easy to understand its "what" or "how", never the "why". Unclear code obscures the "how" or "what", but clear code doesn't reveal "why".
Every "how" breaks down into smaller steps. Of course, those smaller steps have a "why" related to their role in relation to the other steps; that's not the "why" that I'm talking about here. Of course we know why we increment a loop counter when walking though an array: to get to the next element. If you start commenting that kind of why, you will soon be flogged by your team mates.
Declarative means that we specify the "what", and the machine deduces the "how".
There is no room for "why", because our present-day machines do not require motivating argumentation in order to do our bidding. They either need the "what" or the "how", or whatever blend of the two that we find convenient.
We need the "why" in the documentation. Such as: why is this program written in the first place? The "why" is not in the code. When code is clear, it's just easy to understand its "what" or "how", never the "why". Unclear code obscures the "how" or "what", but clear code doesn't reveal "why".
Every "how" breaks down into smaller steps. Of course, those smaller steps have a "why" related to their role in relation to the other steps; that's not the "why" that I'm talking about here. Of course we know why we increment a loop counter when walking though an array: to get to the next element. If you start commenting that kind of why, you will soon be flogged by your team mates.
code can be much more precise and clear than English
Agreed, code is much more precise than English. But precision is not the same thing as being meaningful and without context, precision is useless. Code generally sucks at context, which is why every programming language worth its salt has comments.
Agreed, code is much more precise than English. But precision is not the same thing as being meaningful and without context, precision is useless. Code generally sucks at context, which is why every programming language worth its salt has comments.
You are missing the point entirely. No matter how clear your code is, it is only expressing the “what”, not the why. I can see that you’re using a binary tree, but why a binary tree and not a hash table? Why a decision forest and not a linear regression? Why a regularization penalty of 0.1 and not 0.2? Why cache A but not B? Why create an object at startup instead of generating it on the fly? You need comments to explain these decisions.
If there's an important difference (e.g. a performance requirement that a hash table wouldn't meet), I'd have a test that checks that. If not, it's probably an arbitrary choice that doesn't matter. If the decision is worth recording, it's worth recording properly.
For the cases you mention a combination of package name, class name and method / function name could serve as a comment with the benefit of making sure any place referencing the code also "documents" why something is happening (tests for example, or callers of your methods).
This is not always possible, and in those cases I also strongly prefer well written, concise comments explaining what is going on and why, ideally with a link to a reference/source which explains the background.
Some examples of method names:
- generateTreeToAllowPartitioningOfItems(...)
- getMatchingRegularizationPenaltyForSpecialCaseX(...)
- getShortTermRedisProxyCache(...)
- createNewPrefilledTemplateObjectForXYZ(...)
I hope this doesn't sound snarky. But more often than not comments do date in my experience (and they don't handle refactoring well), while (compiler-known) names are handled as 1st class citizens by the current IDEs and thus are corrected and updated anywhere.
In code reviews we usually aim for "low comment" density, the implementer shouldn't explain what or why he was doing, the reviewer has to understand just from the code (as it would happen if she/he has to maintain it later on). The review is "not good" or even fails if the reviewer doesn't understand why and what is happening. The outcome will in most cases be an improved design, not more comments.
This is not always possible, and in those cases I also strongly prefer well written, concise comments explaining what is going on and why, ideally with a link to a reference/source which explains the background.
Some examples of method names:
- generateTreeToAllowPartitioningOfItems(...)
- getMatchingRegularizationPenaltyForSpecialCaseX(...)
- getShortTermRedisProxyCache(...)
- createNewPrefilledTemplateObjectForXYZ(...)
I hope this doesn't sound snarky. But more often than not comments do date in my experience (and they don't handle refactoring well), while (compiler-known) names are handled as 1st class citizens by the current IDEs and thus are corrected and updated anywhere.
In code reviews we usually aim for "low comment" density, the implementer shouldn't explain what or why he was doing, the reviewer has to understand just from the code (as it would happen if she/he has to maintain it later on). The review is "not good" or even fails if the reviewer doesn't understand why and what is happening. The outcome will in most cases be an improved design, not more comments.
But those method names are still hard to relate to the business cases your customer requested. So you implemented something for some reason; your code and methods tell you what you implemented but not why... Why did you use a tree? I read your top level code and think ; dude, that would have been so much simpler and faster using a Wobble instead of a Tree! Then I try that and it turns out it has to be a Tree; you went through the same process, did not tell me why and I lost a day retrying. For instance.
(assuming, which you should always assume imho, that you left the company many years ago when this event occurs)
(assuming, which you should always assume imho, that you left the company many years ago when this event occurs)
If I wrote an explanation then what would check that explanation? Maybe I write "we use a Tree instead of a Wobble because Wobble doesn't support the APIs we need". But then maybe when you come to work on it, it turns out that the current version of Wobble does support those APIs. Maybe it's actually better at them than Tree. Whereas if I have a unit test around Tree that exercises the kind operations that we need to do, then you can just try dropping Wobble in there and see for yourself whether it works or not.
> code can be much more precise and clear than English. [my emphasis.]
As a common feature of most higher-level languages is that they co-opt natural language terms (and also mathematical notation, which is an option in commenting) with the intent to increase clarity, can you show us an example where code is more clear than natural language in explaining both what it is doing and why?
If you are working in something like APL, I can see there might be a case...
I am not so much interested in the precision issue, as both code and language can be very precisely wrong or right.
As a common feature of most higher-level languages is that they co-opt natural language terms (and also mathematical notation, which is an option in commenting) with the intent to increase clarity, can you show us an example where code is more clear than natural language in explaining both what it is doing and why?
If you are working in something like APL, I can see there might be a case...
I am not so much interested in the precision issue, as both code and language can be very precisely wrong or right.
> Human programmers have a limited discipline budget
You think humans are bad, try working with Lobster programmers, they get work done, but their coding style is just horrible (they use tabs).
You think humans are bad, try working with Lobster programmers, they get work done, but their coding style is just horrible (they use tabs).
>If the developer doesn't remember to do it when making changes, then the code reviewer can catch it and enforce it.
They can. Just after correcting all the buffer overflows and before fixing all the use-after-frees. Then the comments can be consumed by all the other teams with the discipline and culture to avoid writing bugs for all time.
They can. Just after correcting all the buffer overflows and before fixing all the use-after-frees. Then the comments can be consumed by all the other teams with the discipline and culture to avoid writing bugs for all time.
Nothing enforces that the code is correct, either, not even tests, as tests are also code, plus there is the utter infeasibility of exhaustive testing.
It does not follow from the possibility for error that a "significant" proportion of comments will necessarily be false. In my experience, that is most likely when an organization has commenting as a mandatory part of its process, which inevitably leads to most comments being trite, and some wrong. Outside of that, comments have not been a problem mainly because they are almost non-existent, even when the code could benefit from them.
It does not follow from the possibility for error that a "significant" proportion of comments will necessarily be false. In my experience, that is most likely when an organization has commenting as a mandatory part of its process, which inevitably leads to most comments being trite, and some wrong. Outside of that, comments have not been a problem mainly because they are almost non-existent, even when the code could benefit from them.
> Comments should be a last-resort stopgap
I'd add; Comments should be saying _why_ this crazy method is here. You can always parse the code to figure out what it does. In a few months/years (depending on your memory) you will not remember _why_ this code was put in place.
I'd add; Comments should be saying _why_ this crazy method is here. You can always parse the code to figure out what it does. In a few months/years (depending on your memory) you will not remember _why_ this code was put in place.
Comments rot, but so does everything else such as type names, tests, variable names, field names, designs, architectures, etc.
Yep - it doesn't help much with a method that's named EmptyCacheToPreventBlugblagCongestion() if external circumstances have stopped the blugblag from ever congesting any longer. So discipline in maintaining the intent of the code is required even if you never write a single comment.
Tests, types and field names get checked on build.
If someone adds functionality to a type so the name isn't really applicable anymore I don't think the build catches that.
As soon as you form something that should conform to the type (according to its name) and find that it doesn't, you notice the problem, and then you fix it once and for all (because the type is defined in one place). So yes, you can have misleading type names in the codebase, but there's a natural pressure to correct them, in a way that there largely isn't for misleading comments.
Nothing enforces correct variable names and descriptive types either, why would you expect those to be more consistently accurate than comments?
They're amenable to automated refactoring, and if you change a type or variable name in one place you're forced to update it everywhere else that uses the same thing.
Comments and `git log -p <file>` to see what the comment originally referred to is pretty useful.
My personal favorite comment style is to wrap a chunk of code in `#{` `#}` blocks and add a general comment of what that chunk of code is accomplishing. Sort of like an inline method.
My personal favorite comment style is to wrap a chunk of code in `#{` `#}` blocks and add a general comment of what that chunk of code is accomplishing. Sort of like an inline method.
All those comments of "blah blah blah gets or sets a value" on my class properties, why do we add all that overhead to our projects to the point we have to use tools like GhostDoc to write our worthless comments? This industry is on crack sometimes.
I simply like comments for adding things like... so and so told me to do this... or simply documenting weird behavior or weird business logic.
I simply like comments for adding things like... so and so told me to do this... or simply documenting weird behavior or weird business logic.
(as others have pointed out here and every where) Comments are NOT for making code understandable. The things you mentioned are for that.
Comments are for things like
1) explaining why this thing that looks wrong or dumb, really isn't. 2) explaining what method/function/class/whatever is suppose to do. Because code can be correct, understandable, and still wrong.
Comments are for things like
1) explaining why this thing that looks wrong or dumb, really isn't. 2) explaining what method/function/class/whatever is suppose to do. Because code can be correct, understandable, and still wrong.
I'm 29 and can barely remember the code I wrote last week.
Comments don't get updated when the requirements for the code change, more often than not end up as misleading.
The only thing worth commenting are actual libraries that are maintained, and 'magic values'.
Comments don't get updated when the requirements for the code change, more often than not end up as misleading.
The only thing worth commenting are actual libraries that are maintained, and 'magic values'.
> For me, any code that I wrote more than 3 weeks, I forgot. That's why I comment the hell out of my code.
I couldn't agree more.
A while back I got in the habit of trying to write code for "me, six-months from now". So, if I think I can explain it to "future me", then I'm happy. Ever since I started doing that, I've been much happier with "past me"'s code.
In addition to comments (particularly around hard to grok code), I've also started trying to be as consistent as possible in code structure and naming schemes. This also helps a lot.
I couldn't agree more.
A while back I got in the habit of trying to write code for "me, six-months from now". So, if I think I can explain it to "future me", then I'm happy. Ever since I started doing that, I've been much happier with "past me"'s code.
In addition to comments (particularly around hard to grok code), I've also started trying to be as consistent as possible in code structure and naming schemes. This also helps a lot.
I write notes to my future self all the time.
Meta comment: This is bullshit and has problems with this that and the other thing. But to fix that I'd have to refactor this other module and I'm not going to do that now. And the other thing I'm drawing a blank.
Meta comment2: I don't think the code needs to do this here. But I can't prove it right now.
Meta comment3: We absolutely need to do this exactly as it is. Because otherwise bad thing happens, which you probably won't see until it hits production.
Meta comment4: This function name isn't correct. But I can't think of a name that is better.
Meta comment: This is bullshit and has problems with this that and the other thing. But to fix that I'd have to refactor this other module and I'm not going to do that now. And the other thing I'm drawing a blank.
Meta comment2: I don't think the code needs to do this here. But I can't prove it right now.
Meta comment3: We absolutely need to do this exactly as it is. Because otherwise bad thing happens, which you probably won't see until it hits production.
Meta comment4: This function name isn't correct. But I can't think of a name that is better.
> Meta comment: This is bullshit
I used to worry about putting emotional blurbs in comments or commit messages, but I'm starting to see their value. A commit that starts "This ugly writing is to appease Roger, the editor obsessed with AP style" lets me know three things:
- Who asked for the change - The source of the content - The fact I disagree but still do it, so future me doesn't pick fights present me avoided
Of course, it could also mean "TODO: revert this commit the minute Roger retires."
I used to worry about putting emotional blurbs in comments or commit messages, but I'm starting to see their value. A commit that starts "This ugly writing is to appease Roger, the editor obsessed with AP style" lets me know three things:
- Who asked for the change - The source of the content - The fact I disagree but still do it, so future me doesn't pick fights present me avoided
Of course, it could also mean "TODO: revert this commit the minute Roger retires."
That's less about emotion and more about context, which absolutely is important to capture. Links to tracking systems, and in more dysfunctional environments, quotes from emails and water cooler conversations can help a lot when going back in time. Generally I put those in the commit message whenever it makes sense, but sometimes it's better to put it in the actual comments themselves.
On the other hand, on the rare occasion that I've commented or committed something based on emotions, I've always regretted it. Granted they never caused problems for me, just a source of internal embarrassment. Still a good enough reason to be thoughtful about what emotions you express.
On the other hand, on the rare occasion that I've commented or committed something based on emotions, I've always regretted it. Granted they never caused problems for me, just a source of internal embarrassment. Still a good enough reason to be thoughtful about what emotions you express.
> Meta comment3: We absolutely need to do this exactly as it is. Because otherwise bad thing happens, which you probably won't see until it hits production.
This is the highest purpose that a comment can fulfill - telling why you are doing something that looks stupid.
This is the highest purpose that a comment can fulfill - telling why you are doing something that looks stupid.
> This function name isn't correct
When dealing with articulate code I often rename the same thing multiple time while I understand it better/clarify it's purpose. Also I love how naming protects the purpose of a variable or method, mentally speaking
When dealing with articulate code I often rename the same thing multiple time while I understand it better/clarify it's purpose. Also I love how naming protects the purpose of a variable or method, mentally speaking
Couldn't agree more, except with meta comment 3 it is very important to describe the bad thing, so that future me knows if he can safely rewrite this or not.
I write multi-line commit comments whenever I do something that's not trivial or has required a large amount of reasoning to perform correctly. As in, first 80 characters explaining the high-level details with (see details) at the end. Then a number of lines with more detailed reasoning.
Most such commits are never looked at again. But every other month or so, I come across a maintenance issue where I wonder about the context of something. In many such cases, I've saved multiple days of false starts or debugging. So it pays off in the long run even if it's only me gaining something from this. (Unlikely; we're a company of 80 developers).
Most such commits are never looked at again. But every other month or so, I come across a maintenance issue where I wonder about the context of something. In many such cases, I've saved multiple days of false starts or debugging. So it pays off in the long run even if it's only me gaining something from this. (Unlikely; we're a company of 80 developers).
Yes, this.
Sometimes you have a choice of a clever way to do something, which saves a few lines and uses neat language tricks that you rarely use * , or just doing things the boring way. As long as the boring way is obvious enough, it's often the better choice.
* I'm looking at you, Ruby... :)
Sometimes you have a choice of a clever way to do something, which saves a few lines and uses neat language tricks that you rarely use * , or just doing things the boring way. As long as the boring way is obvious enough, it's often the better choice.
* I'm looking at you, Ruby... :)
There's truth to both sides. Depends on the comment really.
``` doesAThing() //does a thing ```
doesn't help anyone.
My rule: Code is for how, comment is for why.
``` doesAThing() //does a thing ```
doesn't help anyone.
My rule: Code is for how, comment is for why.
> Code is for how, comment is for why.
Excellent. For interfaces, other code that uses the interface (perhaps even tests) can also help to document the "why".
Excellent. For interfaces, other code that uses the interface (perhaps even tests) can also help to document the "why".
Yeah, whoever told you that has never had the sinking feeling of digging in to a 300 or 1000 LOC function with a pretty refactor in mind only to see just how much of the system relies on that one function. It's really only an issue if you try to be diligent about testing the work you produce, in which case that little refactor could cost your team a week or a month of additional testing while they verify that you didn't break anything.
Or you could sneak one more little if statement or some copy/paste in there to fix it instead, and add a little comment that says "If you modify this line, please verify that your change doesn't impact Line XXX of file FFFF as well." And then you're done in less than a day and have saved a huge amount of testing.
Or you could sneak one more little if statement or some copy/paste in there to fix it instead, and add a little comment that says "If you modify this line, please verify that your change doesn't impact Line XXX of file FFFF as well." And then you're done in less than a day and have saved a huge amount of testing.
This is especially problematic in machine-control code.
I've seen code from an otherwise highly capable developer that contained 1000+ LOC functions. When asked why he couldn't do a refactor the answer boiled down to fear. When the only real way to test the code is by physically running a machine through a number of scenarios, many of which are difficult at best to recreate, you become very reluctant to refactor or clean it up.
Like all problems, it's best to nip it in the bud before things get that far out of line.
I've seen code from an otherwise highly capable developer that contained 1000+ LOC functions. When asked why he couldn't do a refactor the answer boiled down to fear. When the only real way to test the code is by physically running a machine through a number of scenarios, many of which are difficult at best to recreate, you become very reluctant to refactor or clean it up.
Like all problems, it's best to nip it in the bud before things get that far out of line.
Line numbers might not stay static. Perhaps referring to a particular function or variable might be better, as well as explaining what it might impact? That way, one can jump to the location, then inspect it to see if the potentially-impacting behaviour still exists.
Definitely useful in the case where it's near-to-impossible to DRY up something, though. Sadly, the limitations of an industrial C environment have led my code to contain a lot of annoying 'If you add something here, make sure to add it to X struct and Y function' comments.
Definitely useful in the case where it's near-to-impossible to DRY up something, though. Sadly, the limitations of an industrial C environment have led my code to contain a lot of annoying 'If you add something here, make sure to add it to X struct and Y function' comments.
Thats also a reason I will include as a comment the unoptimized code with comments whenever I do optimized crazycode.
That way, I can understand what is actually being done. And I can then re-analyze why I did the shortcuts to get to optimization.
But 99% of the time, we dont need to optimize. CPU/RAM is cheap. But those 1% of the times when you're going from N^2 to N^logN ... Welll.....
That way, I can understand what is actually being done. And I can then re-analyze why I did the shortcuts to get to optimization.
But 99% of the time, we dont need to optimize. CPU/RAM is cheap. But those 1% of the times when you're going from N^2 to N^logN ... Welll.....
Did you mean N*logN? I don't think going to N^logN is what you want ;)
Sigh, yep!
Thats what I get for trying to type it on a phone browser!
Thats what I get for trying to type it on a phone browser!
As I've matured as a developer I generally find it easier to read and understand code, whether it be my own or others. As a junior this is something I definitely struggled with.
Lemma:
> Learned as junior: Legacy code is hard to read. Understood as senior: Legacy code that I wrote myself is hard to read.
Lemma:
> Learned as junior: Technical skills matter most. Understood as senior: Communication skills matter most.
Theorem:
Communication needs to target the people of the future.
> Learned as junior: Legacy code is hard to read. Understood as senior: Legacy code that I wrote myself is hard to read.
Lemma:
> Learned as junior: Technical skills matter most. Understood as senior: Communication skills matter most.
Theorem:
Communication needs to target the people of the future.
Outstanding observation, thank you!
Way back in the day, my boss made a lovely observation - 'write your code like it's going to be maintained by an axe murderer who has your home address, and nothing to lose.'
Simple guidelines to live your life by ;)
Simple guidelines to live your life by ;)
Attribution: “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” — John F Woods, 1991 in comp.lang.c++¹
(I do not know who first replied, ‘I do know where I live.’)
¹ https://groups.google.com/forum/#!msg/comp.lang.c++/rYCO5yn4...
(I do not know who first replied, ‘I do know where I live.’)
¹ https://groups.google.com/forum/#!msg/comp.lang.c++/rYCO5yn4...
Did he call it "his" observation? I am yet to find a likeable person quoting this.
All excellent points. I got used to filling my code with comments in the spirit of having a conversation with someone to whom I am explaining how an why. Thirty years later I can look at any of my code and quickly understand it. In sharp contrast to this I find most open source code to be difficult and laborious to understand due to the almost total lack of useful comments.
Sometimes you encounter some questionable code and you wonder: "What idiot wrote this?" So you `git blame` and you find out "Oh, I'm that idiot."
I have been in this situation and tried to remember what was going on while I wrote the questionable code. It frequently came down to a day full of interruptions and context switching. Also motivation plays a tremendous role, I know that whenever I have to work on a code base I don’t understand and don’t want to have anything to do with it long term, it ruins my ability to focus.
> Learned as junior: New tech solves old problems.
> Understood as senior: New tech creates new problems.
Yep! When you use "new tech", you're making a bet, and not all bets pay off. If you're cautious, you'll hold off until new tech is proven (or pilot it cautiously before migrating). If you're possessed with good judgment, you'll be discriminating in which new techs you adopt. If you have both virtues, you may even gain a competitive advantage.
> Understood as senior: New tech creates new problems.
Yep! When you use "new tech", you're making a bet, and not all bets pay off. If you're cautious, you'll hold off until new tech is proven (or pilot it cautiously before migrating). If you're possessed with good judgment, you'll be discriminating in which new techs you adopt. If you have both virtues, you may even gain a competitive advantage.
> Understood as senior: Communication skills matter most.
I've been of a similar opinion at some point, but now that I see people _optimizing for communication_ as juniors in lieu of actual technical skills, I say: both matter a ton. I hate dealing with a junior that is an extremely good people person but a terrible developer: they tend to think they got everything covered just because people like them so much, even when their actual solutions are terrible.
I've been of a similar opinion at some point, but now that I see people _optimizing for communication_ as juniors in lieu of actual technical skills, I say: both matter a ton. I hate dealing with a junior that is an extremely good people person but a terrible developer: they tend to think they got everything covered just because people like them so much, even when their actual solutions are terrible.
>Learned as junior: Technical skills matter most.
>Understood as senior: Communication skills matter most.
I see this often, but it needs to be said with a caveat - the second line presupposes the first. Without the first, the second doesn't really matter (or it does but you're in the wrong career).
>Understood as senior: Communication skills matter most.
I see this often, but it needs to be said with a caveat - the second line presupposes the first. Without the first, the second doesn't really matter (or it does but you're in the wrong career).
Actually it is very disfuncional for me to be in a company that communication skills are ahead of technical.
"Understood as senior: Legacy code that I wrote myself is hard to read."
Your comment came at the perfect time. I just finished debugging a "high urgency" problem with a program I developed and maintained for the past 10 years.
The program started simple with a small list of rules to apply against data sets. Over time the list became a tree of rules that expanded in both breadth and depth. It was refactored once to get the design in line with the rules of the time.
The "high urgency" issue turned out to be the program working correctly. But, the functional user wasn't able to keep in mind some of the rules he set. It took me a half hour, with lots of "why did I do that", to explain it again to the user.
Your comment came at the perfect time. I just finished debugging a "high urgency" problem with a program I developed and maintained for the past 10 years.
The program started simple with a small list of rules to apply against data sets. Over time the list became a tree of rules that expanded in both breadth and depth. It was refactored once to get the design in line with the rules of the time.
The "high urgency" issue turned out to be the program working correctly. But, the functional user wasn't able to keep in mind some of the rules he set. It took me a half hour, with lots of "why did I do that", to explain it again to the user.
> Understood as senior: Legacy code that I wrote myself is hard to read.
As it should be. If your code from a five to ten years ago doesn't make you cringe at least a little bit, the right way to view that is not that you were doing a good job back then, but that you haven't gotten any better since then.
As it should be. If your code from a five to ten years ago doesn't make you cringe at least a little bit, the right way to view that is not that you were doing a good job back then, but that you haven't gotten any better since then.
There are absolutely things I was better at back then, mostly because then I spent all my time doing nothing but programming and now a lot of time goes to other activities (meetings, planning, writing, etc).
Well, yeah, good point. I guess I should temper that with if you're still a full time professional software engineer. I wouldn't expect it to apply to someone that moves partially of fully to a different type of job or activity.
It isn't as simple as better skilled or not. Many times having more understanding about the problem may open your eyes to better / simpler design, or you now don't have any rushing matter that fuel bad design in the past.
I disagree with this perspective. You of yesteryear is in many ways just another programmer you have to work with; if that makes you cringe, you may be taking a bit too much pride in your work.
> You of yesteryear is in many ways just another programmer you have to work with
Taking that idea to the extreme of not having any feeling of ownership or pride (or lack thereof) in your past work seems rather silly to me. It wasn't just some other programmer, it was you.
I'm not saying you should cringe because the code is bad, but because you should have a sense of "well, I could have saved myself some trouble or made this cleaner/more obvious if I only knew then what I know now."
Taking that idea to the extreme of not having any feeling of ownership or pride (or lack thereof) in your past work seems rather silly to me. It wasn't just some other programmer, it was you.
I'm not saying you should cringe because the code is bad, but because you should have a sense of "well, I could have saved myself some trouble or made this cleaner/more obvious if I only knew then what I know now."
Or maybe you cringe at your old 'good' code because you spent too much time on things that ultimately didn't matter.
>Understood as senior: Communication skills matter most.
I can't speak enough on this one. In our craft, The better one is at communication skills, the more effective their technical skills will be.
I can't speak enough on this one. In our craft, The better one is at communication skills, the more effective their technical skills will be.
There's also a strong correlation between strong communication skills and strong technical skills in our industry that demands frequent learning of new skills. So not only does strong communication augment technical skills, it also signals its strength which is also valuable to software developers.
> Learned as junior: If you report an OS bug or some other deep problem, seniors will not believe you and assume you're making excuses for your own bugs and lack of understanding.
My mum told me "if you think you found a bug in the compiler or OS... you're wrong". This advice applies until you're good enough to know it doesn't. She was right.
My mum told me "if you think you found a bug in the compiler or OS... you're wrong". This advice applies until you're good enough to know it doesn't. She was right.
One of the first rules from the book The Pragmatic Programmer is "SELECT isn't broken". (It might even be the first rule.)
I wish my mother knew what a compiler was.
Heh, at 19 she was the PL/1 expert for the Asia/Pacific region. Mum's a badass.
> Learned as junior: New tech solves old problems.
> Understood as senior: New tech creates new problems.
This is one all the people who push "new and shiny" need to learn.
> Understood as senior: New tech creates new problems.
This is one all the people who push "new and shiny" need to learn.
I mean, yes and no, sometimes an old systems so bad it really needed to be killed off and replaced. Or would you rather everyone stick to coding in VB6? I rather we all use C# instead of VB6 ;) I'm not implying we only ever use C#, I know there's other languages, just illustrating a shift in the MS windows development ecosystem that was for the better.
VB 6 is probably not a good example.
Even nowadays many languages don't have features that VB6 offered incl. WYSIWYG. Debugging capabilities of modern languages/environments are still often not even close to what VB6 offered 20+ years ago.
C# certainly is outstanding but I think Microsoft made a gigantic mistake by killing VB6 the way they did.
Microsoft's prevented a large amount of people to write applications, since a new ecosystem like C# or VB.net was significantly more difficult to learn and understand.
In retrospect Python or Node probably took VB6's place, so Microsoft just lost out on a huge market there. Bad management decision.
Even nowadays many languages don't have features that VB6 offered incl. WYSIWYG. Debugging capabilities of modern languages/environments are still often not even close to what VB6 offered 20+ years ago.
C# certainly is outstanding but I think Microsoft made a gigantic mistake by killing VB6 the way they did.
Microsoft's prevented a large amount of people to write applications, since a new ecosystem like C# or VB.net was significantly more difficult to learn and understand.
In retrospect Python or Node probably took VB6's place, so Microsoft just lost out on a huge market there. Bad management decision.
> I mean, yes and no, sometimes an old systems so bad it really needed to be killed off and replaced.
I don't believe this is the spirit in which this was meant. If the old system is out of date and there are buggy libraries that aren't being maintained, that is a WHOLE different issue.
I don't believe this is the spirit in which this was meant. If the old system is out of date and there are buggy libraries that aren't being maintained, that is a WHOLE different issue.
> Learned as junior: If you report an OS bug or some other deep problem, seniors will not believe you
Same thing happens in reverse! ;)
A few years back I told 3 devs who reported to me that there was a bug in Laravel database sub system.
The bug was: If you use the word "returning" in any Laravel insert query the system would crash (Laravel 3 & 4).
None of my guys would believe me!
I finally tracked the bug down to
> laravel/database/connection.php
> public function query($sql, $bindings = array()) > { > ... etc ... > elseif (stripos($sql, 'insert') === 0 and stripos($sql, 'returning') !== false)
I sent an email to the Laravel team and never got a response... but the bug stopped happening some time after that ;)
I think it was relate to mySQL version as well.
Same thing happens in reverse! ;)
A few years back I told 3 devs who reported to me that there was a bug in Laravel database sub system.
The bug was: If you use the word "returning" in any Laravel insert query the system would crash (Laravel 3 & 4).
None of my guys would believe me!
I finally tracked the bug down to
> laravel/database/connection.php
> public function query($sql, $bindings = array()) > { > ... etc ... > elseif (stripos($sql, 'insert') === 0 and stripos($sql, 'returning') !== false)
I sent an email to the Laravel team and never got a response... but the bug stopped happening some time after that ;)
I think it was relate to mySQL version as well.
> If you report an OS bug or some other deep problem, seniors will not believe you and assume you're making excuses for your own bugs and lack of understanding.
Similarly, one thing I learned is that if I find a bug with an OS or platform, 9 times out of 10 it's actually due to some problem in my code or my own lack of understanding :)
Similarly, one thing I learned is that if I find a bug with an OS or platform, 9 times out of 10 it's actually due to some problem in my code or my own lack of understanding :)
Can suggest it's more like 999 times out of 1000?
> Understood as senior: Communication skills matter most.
can you give examples ?
can you give examples ?
I can try.
Teaching juniors can be more productive than coding. Being 10x by yourself is less good than 3x-ing a whole team. Even better, teach everyone to be as fast & good as you. Good teaching requires good communication and building trust.
Understanding priorities and goals is absolutely critical to making good choices while programming. Writing good code under reasonable deadlines in an organization necessarily involves a lot of discussion about what constitutes an acceptable solution, what doesn’t, how long it might take, how long is too long, what features are nice but not necessary.
Over-engineering, for example, is extremely common, and is caused in part by not correctly balancing goals and priorities with time budgets. It’s usually a symptom of mis-communication.
Can’t even count how many times I’ve seen a programmer go off the rails building stuff that wasn’t asked for, only to have a meeting several weeks later that invalidated weeks of work when the goals were clarified. (That includes me, btw.)
Making large changes and leading a group of programmers often requires a lot of convincing and rallying work along with the technical planning, sometimes much more than you’d expect. It also requires the ability to put yourself aside and allow others to contribute to the design, even when you think your technical solution is superior.
Getting promoted is, in my experience, most commonly a process of demonstrating to others that you listen well, organize well, work well with others, get things done under deadlines, understand and report what juniors are doing to management, budget well, internalize the organizational goals and contribute meaningfully to meeting those goals.
In short, it’s because teamwork is important.
Teaching juniors can be more productive than coding. Being 10x by yourself is less good than 3x-ing a whole team. Even better, teach everyone to be as fast & good as you. Good teaching requires good communication and building trust.
Understanding priorities and goals is absolutely critical to making good choices while programming. Writing good code under reasonable deadlines in an organization necessarily involves a lot of discussion about what constitutes an acceptable solution, what doesn’t, how long it might take, how long is too long, what features are nice but not necessary.
Over-engineering, for example, is extremely common, and is caused in part by not correctly balancing goals and priorities with time budgets. It’s usually a symptom of mis-communication.
Can’t even count how many times I’ve seen a programmer go off the rails building stuff that wasn’t asked for, only to have a meeting several weeks later that invalidated weeks of work when the goals were clarified. (That includes me, btw.)
Making large changes and leading a group of programmers often requires a lot of convincing and rallying work along with the technical planning, sometimes much more than you’d expect. It also requires the ability to put yourself aside and allow others to contribute to the design, even when you think your technical solution is superior.
Getting promoted is, in my experience, most commonly a process of demonstrating to others that you listen well, organize well, work well with others, get things done under deadlines, understand and report what juniors are doing to management, budget well, internalize the organizational goals and contribute meaningfully to meeting those goals.
In short, it’s because teamwork is important.
Alright, I just failed to parse what communication could mean. I see it clearly now, leadership, team work, social skills, they do indeed matter a ton.
I once worked with a brilliant engineer. He was from Hong Kong. He struggled to express his ideas in English. We tended to let him show us in code instead.
Sometimes this worked. Sometimes it really, really didn't. It also meant we had a very difficult time discussing larger architectural questions with him or giving him useful feedback on his code.
Sometimes this worked. Sometimes it really, really didn't. It also meant we had a very difficult time discussing larger architectural questions with him or giving him useful feedback on his code.
I’ve recently had a similar problem, only in my case I’m the foreigner who can’t speak the local language. It’s fine except in meetings.
Junior dev me: meetings are a waste of time.
Senior dev me: meetings are the steering wheel, the developers are the engine (https://kitsunesoftware.wordpress.com/2018/01/29/utility-fun...)
Junior dev me: meetings are a waste of time.
Senior dev me: meetings are the steering wheel, the developers are the engine (https://kitsunesoftware.wordpress.com/2018/01/29/utility-fun...)
Well that's half cultural, I meant in a context of shared native tongue. Now international work does create lots of hurdles because you can't translate things above casual smalltalk. I guess that's where maths could help.
Articulating requirements or architecture to either stakeholders or juniors is key to being able to actually do your job as a senior (whether that's coding yourself, code reviews, planning, interviews, etc etc).
If nothing else, it is a godsend when talking to PMs. A junior may be like "this code sucks, it is too complex!!" where a more senior can be more like "This code is not written in a good way. If we had some time to rewrite these particular parts, we could provide these features to the users".
Being able to couple value to what you do, or for that matter, to what might not be worth pursuing, is a very good skill. And be sure to not often say no to a PM asking for a feature, but rather give an alternative "doing that is quite complex and might take us half a year. How about we do this other thing that gets us 90% of the way there, but only take a week to implement?"
Being able to couple value to what you do, or for that matter, to what might not be worth pursuing, is a very good skill. And be sure to not often say no to a PM asking for a feature, but rather give an alternative "doing that is quite complex and might take us half a year. How about we do this other thing that gets us 90% of the way there, but only take a week to implement?"
There's no hard-and-fast rule on this but generally junior projects are isolated where you may only have one stakeholder. Growing into a more senior role, your actions generally have greater breadth that affect more teams/clients/orgs. Technical chops are worthy but I can guarantee that your stakeholders would rather have amazing communication for things like progress, deployment, etc. than how efficient or beautifully written the project is.
[deleted]
It's mainly used when discussing task and making architectural / design decision. Junior usually talk in techincal / implementation terms. While senior usually talk in broader / general / business term.
Moreover junior usually have hard time expressing techincal problem.
Moreover junior usually have hard time expressing techincal problem.
[deleted]
> Understood as senior: If a junior programmer tells me they found a system-level bug, I won't believe them and will tell them to go figure out what's wrong with their code.
Me: 'Even a blind squirrel finds a nut once in a while'
Me: 'Even a blind squirrel finds a nut once in a while'
Horses, not zebras. But yes, there are a few zebras in the world also.
Depends on what they are doing.
Oh you found a 'bug' in Mac OS, Windows, or Linux? Probably not.
Oh you found a 'bug' some open source library? Maybe.
Or in our in house developed framework? Probably.
In house framework I wrote? Certain of that.
Oh you found a 'bug' in Mac OS, Windows, or Linux? Probably not.
Oh you found a 'bug' some open source library? Maybe.
Or in our in house developed framework? Probably.
In house framework I wrote? Certain of that.
> Understood as senior: New tech creates new problems.
Related: There are no new problems.
Related: There are no new problems.
[deleted]
Things I've learned:
I'll never be a senior programmer.
> Understood as senior: Legacy code that I wrote myself is hard to read.
Ha, yes, I occasionally come across code I wrote years before and have a few "WTF moments"!
Ha, yes, I occasionally come across code I wrote years before and have a few "WTF moments"!
I always find myself saying “Who is the shithead who wrote... oh...”
Its a good sign - means you are learning and getting better.
New tech solves your existing problems and creates new ones. I have a big pile of problems I have had for many years that I’d love to trade for some new ones. I’m happy to fix one problem and get 5 new ones. I’m happy to get rid of an easy problem and get a new much harder problem. The important thing is that I get some new problems, and nothing will do that like new tech.
> Understood as senior: If a junior programmer tells me they found a system-level bug, I won't believe them and will tell them to go figure out what's wrong with their code.
And, yet, it does happen. The important part as the senior guy is to make the junior guy create a test case and then cut it to the bone until it is obvious where the bug is.
Story time: It's mid ninteen-ninety-mumble and your intrepid hero is a junior programmer handling multi-site integration and testing tool infrastructure. This being the time when the Swiss Army Chainsaw(tm) (aka Perl 4) is well and truly entrenched in the sysadmin and toolsmith programmers, my technical superiors throw me a couple of Perl books, set my deliverable date impossibly soon, and tell me to get going post haste.
So, I code. It's not a lot of code, but it is parsing and matching files in 3 different formats from 3 different sites. Of course, I hear what you are saying: "Perl and parsing is like mixing ammonia and chlorine--and probably more painful." Yes, I concur. But, it is the tool at hand in the long forgotten mists of time when RAM was expensive and spinning rust still resembled an iron brick. So, off I go with regexes for parsing (Yes, I know, now I have 3 problems).
And everything worked quite swimmingly. Except for a bit of idiocy that nobody could track down that occasionally flagged a couple of records as mismatched when manual inspection showed they really were not. Nobody minded that much as the scripts got 99.99% of the job done and didn't give a false negative, so: "Ship it, junior."
And so we did.
However, the bug annoyed me because I had to got clean up the false positives when they fired. And, if I am anything, I am a VERY lazy programmer--and this was preventing me from being lazy.
So, I eventually am waiting for one of the other groups to deliver, and I go spelunking for a testcase.
Spelunking? HAH! Cave diving is a better analogy.
The program took the most inclusive of the syntaxes, used each record from that to build a regex to look for the corresponding record in the other syntaxes, matched what it could and flagged what remained.
So, the program was building a dynamic regex on-the-fly and then using it. Not a huge deal, but the regexes were larger than most people were probably comfortable with. No problem, I validated this on much smaller records out to REALLY big records, and they work well.
Except for those weird cases ...
So, I'm looking through a case that works and trying to compare it to a case that doesn't. And I accidentally fat-finger some character set match and delete a character that shouldn't matter.
And the regex fails ... provoking the Asimovean "That's funny ..."
So I delete another character ... and it works again. What?!?!?!
So, I add a character. And it fails. And I add another. And it works again.
I stared at that regex for what felt like EONS until the light bulb went on.
The one that worked? 511 characters or 513 characters. The one that failed? 512 characters.
So, yes, I, a total Perl n00b managed to find a bug in Perl 4 in my first ever Perl program.
Sometimes the junior dude gets really unlucky and finds an actual system-level bug.
And, yet, it does happen. The important part as the senior guy is to make the junior guy create a test case and then cut it to the bone until it is obvious where the bug is.
Story time: It's mid ninteen-ninety-mumble and your intrepid hero is a junior programmer handling multi-site integration and testing tool infrastructure. This being the time when the Swiss Army Chainsaw(tm) (aka Perl 4) is well and truly entrenched in the sysadmin and toolsmith programmers, my technical superiors throw me a couple of Perl books, set my deliverable date impossibly soon, and tell me to get going post haste.
So, I code. It's not a lot of code, but it is parsing and matching files in 3 different formats from 3 different sites. Of course, I hear what you are saying: "Perl and parsing is like mixing ammonia and chlorine--and probably more painful." Yes, I concur. But, it is the tool at hand in the long forgotten mists of time when RAM was expensive and spinning rust still resembled an iron brick. So, off I go with regexes for parsing (Yes, I know, now I have 3 problems).
And everything worked quite swimmingly. Except for a bit of idiocy that nobody could track down that occasionally flagged a couple of records as mismatched when manual inspection showed they really were not. Nobody minded that much as the scripts got 99.99% of the job done and didn't give a false negative, so: "Ship it, junior."
And so we did.
However, the bug annoyed me because I had to got clean up the false positives when they fired. And, if I am anything, I am a VERY lazy programmer--and this was preventing me from being lazy.
So, I eventually am waiting for one of the other groups to deliver, and I go spelunking for a testcase.
Spelunking? HAH! Cave diving is a better analogy.
The program took the most inclusive of the syntaxes, used each record from that to build a regex to look for the corresponding record in the other syntaxes, matched what it could and flagged what remained.
So, the program was building a dynamic regex on-the-fly and then using it. Not a huge deal, but the regexes were larger than most people were probably comfortable with. No problem, I validated this on much smaller records out to REALLY big records, and they work well.
Except for those weird cases ...
So, I'm looking through a case that works and trying to compare it to a case that doesn't. And I accidentally fat-finger some character set match and delete a character that shouldn't matter.
And the regex fails ... provoking the Asimovean "That's funny ..."
So I delete another character ... and it works again. What?!?!?!
So, I add a character. And it fails. And I add another. And it works again.
I stared at that regex for what felt like EONS until the light bulb went on.
The one that worked? 511 characters or 513 characters. The one that failed? 512 characters.
So, yes, I, a total Perl n00b managed to find a bug in Perl 4 in my first ever Perl program.
Sometimes the junior dude gets really unlucky and finds an actual system-level bug.
The big one for me was the realisation that the code doesn't matter. I mean sure, it does, to us. It's what we do. But really, code doesn't matter.
To the end user, what matters is that we solve their problem. We let them do their job, and we make that job as easy as possible. And that's what they pay us for.
And to the company we work for, what matters is that we solve the end user's problem, and that we do so in an expedient and economical manner, so that it costs less for us to do so than the customer pays us.
Of course, for us to continue doing this, in the long term, we need to innovate and architect and uphold standards and stay on top of technical debt. And all of that put together is "make the code good". But that's an end to the means, and the customer doesn't care what horrors awake when they click that dialog box button as long as the result they needed pops out at the end.
To the end user, what matters is that we solve their problem. We let them do their job, and we make that job as easy as possible. And that's what they pay us for.
And to the company we work for, what matters is that we solve the end user's problem, and that we do so in an expedient and economical manner, so that it costs less for us to do so than the customer pays us.
Of course, for us to continue doing this, in the long term, we need to innovate and architect and uphold standards and stay on top of technical debt. And all of that put together is "make the code good". But that's an end to the means, and the customer doesn't care what horrors awake when they click that dialog box button as long as the result they needed pops out at the end.
This is why calling people "coders" annoys the hell out of me. There was a popular blog post a long way back[1] about how you shouldn't call yourself a "programmer" because that builds the expectation that programs are the key output of your work. "Coder" takes this problem even further — your job is no longer to build a program (with all the thought and design work that entails), but rather to type out code.
I'm not a coder, or a programmer. I'm a problem solver, and I tend to specialise in the sort of software infrastructure-y problems that are usually solved through code. If you think of yourself as a problem solver first and foremost, then you'll often realise that the best solution involves zero code.
This ${problem}-solver versus ${solution}-user gets even worse when people go beyond define themselves as technology-du-jour users, doesn't matter if it's Rails, React, blockchains, big data, ML, AI...
1. https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
I'm not a coder, or a programmer. I'm a problem solver, and I tend to specialise in the sort of software infrastructure-y problems that are usually solved through code. If you think of yourself as a problem solver first and foremost, then you'll often realise that the best solution involves zero code.
This ${problem}-solver versus ${solution}-user gets even worse when people go beyond define themselves as technology-du-jour users, doesn't matter if it's Rails, React, blockchains, big data, ML, AI...
1. https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
Problem solver can be the title of pretty much any job though.
"I'm a problem solver, I fix problems by diving down and welding broken things at oil platforms"
"I'm a problem solver, I make sure the books are correct at the end of the financial year"
etc. I mean it is correct but if someone calls themselves a coder/programmer/software engineer (even if they are not real engineers) then I know roughly what they are doing each day even if the value they create and what they are working on can be wildly different. Just like a deep sea welder.
"I'm a problem solver, I fix problems by diving down and welding broken things at oil platforms"
"I'm a problem solver, I make sure the books are correct at the end of the financial year"
etc. I mean it is correct but if someone calls themselves a coder/programmer/software engineer (even if they are not real engineers) then I know roughly what they are doing each day even if the value they create and what they are working on can be wildly different. Just like a deep sea welder.
Yeah, I wasn't entirely clear on that bit :) There absolutely is plenty of room for a word more specific than "problem-solver". But our choice of words matters — words carry nuance.
In some ways I'd consider "software engineer" as equivalent to "novelist" or "journalist" where "programmer" maps to "writer" and "coder" corresponds to "typist". Software engineer, novelist, journalist all encapsulate a lot of responsibilities, where writer and programmer both talk just about primary means of achieving the job, and coder/typist bring it down to the mechanical skills you require to get the job done.
In some ways I'd consider "software engineer" as equivalent to "novelist" or "journalist" where "programmer" maps to "writer" and "coder" corresponds to "typist". Software engineer, novelist, journalist all encapsulate a lot of responsibilities, where writer and programmer both talk just about primary means of achieving the job, and coder/typist bring it down to the mechanical skills you require to get the job done.
I actually go the opposite route; I hate calling myself an engineer, because that word actually carries weight due to older, more established professions. The tech/software industry wants the prestige of that title without the work and effort that goes into it.
We are not engineers. We have no standardized certification process or tests. We have no (or very little) accountability. We have no codes of ethics. We may or may not be following proper, accepted development workflows. We may not even know what industry standard processes are.
I am a software developer because I solve problems primarily via software. This can and does include many different responsibilities and skillsets, but at the end of the day I primarily architect and write code.
It's up to you to educate the layperson as to what a software developer actually does. Although I'm not a writer, I understand that a "writer" doesn't literally only write. People can understand better than you're giving them credit for, I think.
We are not engineers. We have no standardized certification process or tests. We have no (or very little) accountability. We have no codes of ethics. We may or may not be following proper, accepted development workflows. We may not even know what industry standard processes are.
I am a software developer because I solve problems primarily via software. This can and does include many different responsibilities and skillsets, but at the end of the day I primarily architect and write code.
It's up to you to educate the layperson as to what a software developer actually does. Although I'm not a writer, I understand that a "writer" doesn't literally only write. People can understand better than you're giving them credit for, I think.
I think of myself as an "engineer", but more in the "keep the steam engine from exploding" sense.
it's fair to say that if you don't like it, then don't speak about it
that's your definition of engineering, or whatever officials that define it
more so, who cares about your skills other than your employer? And your employer cares about your skills, why should he care about your title?
even if other programmers who like to address themselves as software engineers, is it up to you to decide whether they can be hired?
It's just a title for god's sake
that's your definition of engineering, or whatever officials that define it
more so, who cares about your skills other than your employer? And your employer cares about your skills, why should he care about your title?
even if other programmers who like to address themselves as software engineers, is it up to you to decide whether they can be hired?
It's just a title for god's sake
> it's fair to say that if you don't like it, then don't speak about it
I would like to see the status quo changed, which is why I do discuss it. Of course it's fair that I hold an opinion and discuss it. There is no obligation for you to respond if you disagree :-)
> that's your definition of engineering, or whatever officials that define it
It's not my sole opinion:
> As with many other professions, the professional status and the actual practice of professional engineering is legally defined and protected by law in some jurisdictions. [3]
It's understood that if someone holds the title 'Engineer', they went through a certification process from a regulated body, traditionally. You can see this for example in countries and per state. [0] [1] [2]
> In Canada the designation "professional engineer" can only be used by licensed engineers and the practice of engineering is protected in law and strictly enforced in all provinces. [3]
In Canada (and I believe some states), it is illegal to sign off an email or other correspondence as a "Professional Engineer" if you're not actually licensed as such. [4]
---
> is it up to you to decide whether they can be hired?
When did I mention hiring? All I said was the term 'engineer' is loosely used in the software industry, and it has absolutely no standard around it.
> employer [...] why should he care about your title?
I wasn't talking about my employer at all. I only referenced skills because I was responding to a portion of the parent comment.
> It's just a title for god's sake
It isn't. How we frame something is very important in my opinion–just as important as the concept itself. [5] If it's "just a title", then people should have no problem calling themselves programmers or developers. However one can see that we call ourselves "engineers" because it sounds prestigious, despite the software industry being a total joke when it comes to standardization or even following basic modern practices consistently.
[0]: https://engineerscanada.ca/accreditation/about-accreditation
[1]: https://ncees.org/engineering/
[2]: https://www.ncbels.org/
[3]: https://en.wikipedia.org/wiki/Regulation_and_licensure_in_en...
[4]: http://www.occupationalhealthandsafetylaw.com/ontario-man-fi...
[5]: Consider for a moment the term "Global Warming" versus "Global Pollution Epidemic". I strongly believe if we had gone with the latter instead of the former, there would not have been pushback to the scale that we've seen. It certainly would have avoided the confusion of "oh, but this winter is so cold, global warming must be a hoax"! It also shifts the focus from an effect of pollution, to the pollution itself. This example is quite different than the software engineer/developer example, but I think it illustrates my point that how things are framed is very important.
We are not software engineers, and we won't be until regulatory bodies exist, and we develop codes of ethics.
I would like to see the status quo changed, which is why I do discuss it. Of course it's fair that I hold an opinion and discuss it. There is no obligation for you to respond if you disagree :-)
> that's your definition of engineering, or whatever officials that define it
It's not my sole opinion:
> As with many other professions, the professional status and the actual practice of professional engineering is legally defined and protected by law in some jurisdictions. [3]
It's understood that if someone holds the title 'Engineer', they went through a certification process from a regulated body, traditionally. You can see this for example in countries and per state. [0] [1] [2]
> In Canada the designation "professional engineer" can only be used by licensed engineers and the practice of engineering is protected in law and strictly enforced in all provinces. [3]
In Canada (and I believe some states), it is illegal to sign off an email or other correspondence as a "Professional Engineer" if you're not actually licensed as such. [4]
---
> is it up to you to decide whether they can be hired?
When did I mention hiring? All I said was the term 'engineer' is loosely used in the software industry, and it has absolutely no standard around it.
> employer [...] why should he care about your title?
I wasn't talking about my employer at all. I only referenced skills because I was responding to a portion of the parent comment.
> It's just a title for god's sake
It isn't. How we frame something is very important in my opinion–just as important as the concept itself. [5] If it's "just a title", then people should have no problem calling themselves programmers or developers. However one can see that we call ourselves "engineers" because it sounds prestigious, despite the software industry being a total joke when it comes to standardization or even following basic modern practices consistently.
[0]: https://engineerscanada.ca/accreditation/about-accreditation
[1]: https://ncees.org/engineering/
[2]: https://www.ncbels.org/
[3]: https://en.wikipedia.org/wiki/Regulation_and_licensure_in_en...
[4]: http://www.occupationalhealthandsafetylaw.com/ontario-man-fi...
[5]: Consider for a moment the term "Global Warming" versus "Global Pollution Epidemic". I strongly believe if we had gone with the latter instead of the former, there would not have been pushback to the scale that we've seen. It certainly would have avoided the confusion of "oh, but this winter is so cold, global warming must be a hoax"! It also shifts the focus from an effect of pollution, to the pollution itself. This example is quite different than the software engineer/developer example, but I think it illustrates my point that how things are framed is very important.
We are not software engineers, and we won't be until regulatory bodies exist, and we develop codes of ethics.
> We are not software engineers, and we won't be until regulatory bodies exist, and we develop codes of ethics.
Nobody said that you are software engineer, you can just call yourself whatever you want
Those who called themselves software engineers are indeed software engineers, no one can forbids it
Fancy term like engineer is for marketing purposes, just like you said it's prestigious, they use it because they want to impress people, anything wrong with that? No, it's correct.
And it's also correct if anyone think they don't fit the title engineer, because it's his/her opinion which the software engineers won't likely give a fuck.
No one can stop them from using the term.
As for the Canada's law, the earth is bigger than that AFAIK. China and US software engineers are waiting for arrest. Except for Texas FYI
Standardization/basic practices mean shits by the way, it's research and development phases during engineering, people can invent what they want in their own ways as long as their products are legit
From Wikipedia:
> Engineers, as practitioners of engineering, are people who invent, design, analyse, build, and test machines, systems, structures and materials to fulfill objectives and requirements while considering the limitations imposed by practicality, regulation, safety, and cost.
Wikipedia can be sue at anytime, as you like
Nobody said that you are software engineer, you can just call yourself whatever you want
Those who called themselves software engineers are indeed software engineers, no one can forbids it
Fancy term like engineer is for marketing purposes, just like you said it's prestigious, they use it because they want to impress people, anything wrong with that? No, it's correct.
And it's also correct if anyone think they don't fit the title engineer, because it's his/her opinion which the software engineers won't likely give a fuck.
No one can stop them from using the term.
As for the Canada's law, the earth is bigger than that AFAIK. China and US software engineers are waiting for arrest. Except for Texas FYI
Standardization/basic practices mean shits by the way, it's research and development phases during engineering, people can invent what they want in their own ways as long as their products are legit
From Wikipedia:
> Engineers, as practitioners of engineering, are people who invent, design, analyse, build, and test machines, systems, structures and materials to fulfill objectives and requirements while considering the limitations imposed by practicality, regulation, safety, and cost.
Wikipedia can be sue at anytime, as you like
> It's understood that if someone holds the title 'Engineer', they went through a certification process from a regulated body, traditionally. You can see this for example in countries and per state. [0] [1] [2]
I think you're misinterpreting the intention of the title of "Professional Engineer". As far as I can tell, it's for accountability for public projects (buildings, power, etc.). It's not strictly limiting what job titles can have the word "engineer" in it.
Most engineers in the aerospace industry don't even take the FE exam. Would you refuse to call most aerospace engineers "engineers" then?
I think you're misinterpreting the intention of the title of "Professional Engineer". As far as I can tell, it's for accountability for public projects (buildings, power, etc.). It's not strictly limiting what job titles can have the word "engineer" in it.
Most engineers in the aerospace industry don't even take the FE exam. Would you refuse to call most aerospace engineers "engineers" then?
I’ve posted it before. But it gets confusing on the global stage. Software Engineer is a protected title in some countries. In mine it means studied a great amount of advanced math in college, almost nothing else. We usually prefix it with a word that tells if we studied 3 or 5 years. SE in US seems to mean just Software Developer I guess?
In Ontario, Canada you can call yourself a Software Engineer. It's prefixing that title with, Professional that will get you in trouble if you're not licensed with the Professional Engineers of Ontario under the Professional Engineers Act.
Requirements are pretty high: http://www.peo.on.ca/index.php/ci_id/2057/la_id/1.htm
But I suppose industry/capitalism loves the fact that we don't require licensing in order to produce software even if use of said software should be safeguarding health, property, economic interests, etc.
Requirements are pretty high: http://www.peo.on.ca/index.php/ci_id/2057/la_id/1.htm
But I suppose industry/capitalism loves the fact that we don't require licensing in order to produce software even if use of said software should be safeguarding health, property, economic interests, etc.
In Quebec, Canada Software Engineer is a protected title and you must be registered with the Ordre des ingénieurs du Québec (http://oiq.qc.ca)
I dunno. I’m a programmer because I like solving problems through code, and I’m not really interested in solving problems outside this toolset. Some artists were exclusively painters, and we still call them that.
Picasso could paint a whole house, in one day - two days tops if you wanted multiple colors.
[deleted]
To you that's great, the article the parent was referencing is from a marketing perspective. He gives the example of quants, they solve financial problems with code. The same is true with data scientist, they just solve analytical problems with code.
In both of these situations they're a programmer, but they sound cooler and will go a lot farther when applying for jobs or moving up in a company than the person who labels themselves as "a programmer".
In both of these situations they're a programmer, but they sound cooler and will go a lot farther when applying for jobs or moving up in a company than the person who labels themselves as "a programmer".
A quant is somebody who specialised in solving very specific finance problems, and a data scientist is somebody who specialised in solving very specific statistics/data analysis problems. I wouldn't hire myself for a data science or quant role any more than I would hire a data scientist or quant for my role, because there's a whole bunch of ancillary skills that we each have that are required by our respective jobs that go above and beyond just programming.
I totally appreciate this attitude. One of the most important qualities of software development is to solve the customer's problem with as little code as possible. "I am coder and therefore the more code I write, the more productive and valuable I am" is a blinkered mindset.
At the same time, you have to actually describe your profession somehow. Everyone solves problems. Solving problems is definition of productive work. A carpenter solves problems by cutting pieces of wood apart and attaching them together. A bricklayer solves problems by stacking bricks on top of each other, with a bit of mortar in between to smooth them out. A car mechanic solves problems by fixing cars. A surgeon solves problems by cutting people open and fixing their insides. Eventually it turns into a bunch of meaningless MBA platitudes. "We don't 'build houses', we 'deliver solutions' to people's shelter-related problems."
If you go to a good surgeon with a problem that isn't going to be fixed with surgery, the surgeon is going to recommend a different solution and possibly even refer you to a different kind of professional. "Hey, you just need to rest that knee and maybe get some physical therapy. Here's a physical therapist I recommend." People understand that surgeons are smart and will occasionally listen to them, so surgeons can get away with this. More importantly, surgeons understand this. Surgeons don't go around thinking, "man, I need to perform even more surgeries because I'm a surgeon and that's what surgeons do" (or, at least, they shouldn't)--they have a deep appreciation of what surgery is and when it is or is not appropriate.
So I don't mind thinking of myself as a programmer, because I'm a programmer the same way a surgeon is a surgeon. If you come to me with a problem that cannot be solved by programming, I will tell you that, because to do otherwise would be a form of malpractice.
At the same time, you have to actually describe your profession somehow. Everyone solves problems. Solving problems is definition of productive work. A carpenter solves problems by cutting pieces of wood apart and attaching them together. A bricklayer solves problems by stacking bricks on top of each other, with a bit of mortar in between to smooth them out. A car mechanic solves problems by fixing cars. A surgeon solves problems by cutting people open and fixing their insides. Eventually it turns into a bunch of meaningless MBA platitudes. "We don't 'build houses', we 'deliver solutions' to people's shelter-related problems."
If you go to a good surgeon with a problem that isn't going to be fixed with surgery, the surgeon is going to recommend a different solution and possibly even refer you to a different kind of professional. "Hey, you just need to rest that knee and maybe get some physical therapy. Here's a physical therapist I recommend." People understand that surgeons are smart and will occasionally listen to them, so surgeons can get away with this. More importantly, surgeons understand this. Surgeons don't go around thinking, "man, I need to perform even more surgeries because I'm a surgeon and that's what surgeons do" (or, at least, they shouldn't)--they have a deep appreciation of what surgery is and when it is or is not appropriate.
So I don't mind thinking of myself as a programmer, because I'm a programmer the same way a surgeon is a surgeon. If you come to me with a problem that cannot be solved by programming, I will tell you that, because to do otherwise would be a form of malpractice.
This is why I always respond to questions about what I do with "software engineer". I've noticed people seem to perceive "engineering" as more serious than "programming", and it helps to promote the idea that I build things to solve problems and don't just sit there turning designs into code.
From Wikipedia:
Engineers, as practitioners of engineering, are people who invent, design, analyse, build, and test machines, systems, structures and materials to fulfill objectives and requirements while considering the limitations imposed by practicality, regulation, safety, and cost.
If you’re doing that you’re an engineer. Hopefully we are all doing that.
Engineers, as practitioners of engineering, are people who invent, design, analyse, build, and test machines, systems, structures and materials to fulfill objectives and requirements while considering the limitations imposed by practicality, regulation, safety, and cost.
If you’re doing that you’re an engineer. Hopefully we are all doing that.
I feel like in areas like software, hardware, electrical, mechanical -construction, there are two descriptors of practitioners and they are at opposite ends; hackers and engineers. At least that’s how I think about myself. Sometimes what I do is hacking together a proof of concept, and sometimes I’m engineering a product.
Of course, there is something in the middle, and for software, that is probably “coders” or “programmers”.
Of course, there is something in the middle, and for software, that is probably “coders” or “programmers”.
Unless you're in certain states where engineer is a protected term.
Engineer is not a "protected term" in any US state that I'm aware of. "Professional Engineer" has a specific licensed meaning but, if I have a degree in mechanical engineering I'm pretty sure I can call myself an engineer anywhere in the US without the licensing police coming after me. (Unless, of course, I imply that I'm licensed when I'm not.)
If you work in a music studio, and you call yourself a sound engineer, no one is going to ask to see your credentials because it's assumed that you engineer sound. The same holds through with software engineering. No one expects you to carry some sort of card. When it comes to structural, or civil engineering, there is a far higher expectation that the things you design are not going to fall down. But we're able to understand this distinction. The idea that we should disallow computer coders/programmers from using the term engineer is not based on reducing confusion...
>When it comes to structural, or civil engineering, there is a far higher expectation that the things you design are not going to fall down.
The big thing is that you need a P.E. in many cases to do things like sign off on drawings for regulators. Some civil engineers, mechanical engineers, etc. have PE's and many don't. In Louisiana, I had business cards with an engineering title and definitely worked as an engineer. At some point, had I remained in the oil business, I'd have gotten a PE because I'd presumably have eventually been in a position where I had approval authority over designs submitted to various government agencies.
The big thing is that you need a P.E. in many cases to do things like sign off on drawings for regulators. Some civil engineers, mechanical engineers, etc. have PE's and many don't. In Louisiana, I had business cards with an engineering title and definitely worked as an engineer. At some point, had I remained in the oil business, I'd have gotten a PE because I'd presumably have eventually been in a position where I had approval authority over designs submitted to various government agencies.
The term "engineer" is definitely protected in Texas, and I think some other states.
Someone ought to tell whoever put all these job listings up (including in Houston): https://www.rigzone.com/a-mud-engineer-jobs/
ADDED: TIL apparently Texas is indeed exceptionally restrictive (in theory) about the use of the term "engineer." [1] I'd be pretty certain this is widely ignored in practice. Leave the oil business aside, I'm guessing that tech companies in Texas probably advertise engineering positions now and then. (Yep: https://jobs.dell.com/location/united-states-texas-round-roc...)
[1] https://www.statesman.com/news/20160903/their-name-on-the-li...
ADDED: TIL apparently Texas is indeed exceptionally restrictive (in theory) about the use of the term "engineer." [1] I'd be pretty certain this is widely ignored in practice. Leave the oil business aside, I'm guessing that tech companies in Texas probably advertise engineering positions now and then. (Yep: https://jobs.dell.com/location/united-states-texas-round-roc...)
[1] https://www.statesman.com/news/20160903/their-name-on-the-li...
The oil industry is setup as nested subcontractors so that no-one with any money is responsible for these kinds of screwups.
Go look into the actual law, you legally can't call yourself an engineer in Texas without a PE, or a couple tiny carveouts (on the order of you work at NASA, and NASA calls you an engineer)
Go look into the actual law, you legally can't call yourself an engineer in Texas without a PE, or a couple tiny carveouts (on the order of you work at NASA, and NASA calls you an engineer)
Replying to your edit: there are no jobs on that Dell site in Texas with engineer in the title. It's including some from Minnesota for some reason.
The problem of listing to dynamic sites. See e.g. https://jobs.dell.com/job/austin/software-senior-engineer-re...
There are doubtless tens of thousands of Texas job listings for "engineer" positions in software and elsewhere. (Software is especially notable only because my understanding is that PE's in software have basically been phased out. So you basically can't get licensed in that branch of engineering even if you have an accredited degree and have met the other requirements.)
There are doubtless tens of thousands of Texas job listings for "engineer" positions in software and elsewhere. (Software is especially notable only because my understanding is that PE's in software have basically been phased out. So you basically can't get licensed in that branch of engineering even if you have an accredited degree and have met the other requirements.)
Not Texas iirc.
As I recall my days in the oil industry, "engineer" was one of the most overused titles. We used to joke about "mud engineers" (reps of the companies that sold the ingredients that made up drilling mud) being, in fact, "mud salesmen." (If you were being generous, they were technicians but they did mostly make recommendations and sell you stuff.)
Heh, on iron ore mine sites we have "hose technicians" whose job is to clean up any spillage with a high pressure hose. There are also jokes about "sanitation engineers" who clean the toilets.
Exactly. I would welcome changes that would bring software engineering to a state where it was a protected term. If someone used that term I could have a high degree of certainty that they would abide by certain standards both professional and ethical. Such as “certain percentage of test coverage” and “certain big-O tolerance” for different project levels. Etc. otherwise I’d write the person off as a coder.
Different places have different standards for engineers, and any other title. It doesn’t matter that you call yourself an engineer in any case. What matters in some cases are the standards you use; is it licensed by someone or something, or is it something else? That’s what you should be asking. What are the standards used?
You can do engineering without following any official standard, and anyone who do engineering is of course an engineer, so yeah, the protected title thing is just meh.
You can do engineering without following any official standard, and anyone who do engineering is of course an engineer, so yeah, the protected title thing is just meh.
I've found myself saying "I, uh, build software" lately.
I guess because I don't like any of the established terms.
I guess because I don't like any of the established terms.
I tend to avoid the word "building" in the context of describing what I do. After all, the compiler does the building :-) "I design and develop software" is what I usually say.
Would be nice if there was a word that captures the idea of someone both designing and constructing the internals of a machine.
Would be nice if there was a word that captures the idea of someone both designing and constructing the internals of a machine.
I try to avoid the word "design" because most people immediately think of graphic design and get the wrong idea of what I do. Even though it's not as technically accurate, I think "building" or "engineering" are better words to use for people not familiar with software development.
It's funny, I've gone from "I'm a coder" -> "I'm a software developer" -> "I'm a software engineer" -> "I'm a developer" -> "I make useful things."
And on the best of days - involves deleting code.
My old boss of exceptional at this. He had hired a lead engineer to architect on code to support some new features and hardware. This lead was working on one of the important module.s It was 1300 lines of convoluted code and still not done. At that point the guy quit. My boss spend a day thinking about the requirements and wrote something that made perfect sense in 30 lines of code all one function.
Fun fact: Bill Atkinson (featured in this story) also wrote the round rect drawing routine for the original Mac.
Source: https://www.folklore.org/StoryView.py?story=Round_Rects_Are_...
Source: https://www.folklore.org/StoryView.py?story=Round_Rects_Are_...
…among many other things, including writing MacPaint, QuickDraw, and HyperCard.
You're spot on. Regarding your last point though my interpretation of the blockchain hype was that the problem of the business was that they needed quick and easy money. Blockchain investors solved that.
Whether you perceive the problem as one worth solving or not, Bitcoin defined a very specific, if extreme, problem it wanted to solve, and proposed an extreme solution to that extreme problem. There's a few other projects (such as Ethereum) that are also trying to solve some very specific problems.
The issue is that the problems that Bitcoin and Ethereum are trying to solve imply almost generating money from thin air. That gave unscrupulous people a lot of silly ideas, on the one hand, and, on the other, gave the people desperate to prove they're "thought leaders" (whatever that means) a lot of different, but still silly, ideas.
The issue is that the problems that Bitcoin and Ethereum are trying to solve imply almost generating money from thin air. That gave unscrupulous people a lot of silly ideas, on the one hand, and, on the other, gave the people desperate to prove they're "thought leaders" (whatever that means) a lot of different, but still silly, ideas.
I often say "That's not programming, that's just typing". (Stole it from someone, can't remember who now.)
this topic never stops, trust me
it's time for you guys to realize this effect from calling yourself "coders"/"programmers"/"problem solvers" are nothing but marketing
It's just to impress those who don't know otherwise
it's time for you guys to realize this effect from calling yourself "coders"/"programmers"/"problem solvers" are nothing but marketing
It's just to impress those who don't know otherwise
> I tend to specialise in the sort of software infrastructure-y problems that are usually solved through code.
So basically a coder?
So basically a coder?
Back in the ice age we were called 'programmer analyst' or even 'system analyst'
machine dompteur ?
I would argue it's even worse than that. It's not just that the code doesn't matter, it's that code is a liability, and the more code you create the more problems you create.
Code has to be maintained, or it will eventually fail as other moving parts around it change their interfaces.
Code rots. Platform norms are always changing, so today's fresh new code becomes tomorrow's smelly old code.
Code interacts with other code. As the volume of code increases linearly, the number of these interactions increases exponentially. Eventually the complexity becomes unmanageable and the whole system has to be rebuilt. The more code you add to a system, the faster you hasten its demise.
All of which means that code is a liability, in the balance-sheet sense of the term. Throwing code at a business problem hurts the bottom line. The goal therefore becomes to throw just enough code at the problem to solve it, and not one line more than that.
This is the difference between inexperienced and experienced developers. Inexperienced developers handle code like it's spackle. Experienced ones handle it like it's uranium.
Code has to be maintained, or it will eventually fail as other moving parts around it change their interfaces.
Code rots. Platform norms are always changing, so today's fresh new code becomes tomorrow's smelly old code.
Code interacts with other code. As the volume of code increases linearly, the number of these interactions increases exponentially. Eventually the complexity becomes unmanageable and the whole system has to be rebuilt. The more code you add to a system, the faster you hasten its demise.
All of which means that code is a liability, in the balance-sheet sense of the term. Throwing code at a business problem hurts the bottom line. The goal therefore becomes to throw just enough code at the problem to solve it, and not one line more than that.
This is the difference between inexperienced and experienced developers. Inexperienced developers handle code like it's spackle. Experienced ones handle it like it's uranium.
I'd agree with you here, I'm still a way off seniority but for me the takeaway from the past 5 years is good code is code that can be deleted with minimal work.
All code we write is going to be wrong in some way as a result of our understanding of the problem domain being incomplete so I'd rather see code with an obvious place to put an if statement than a lovingly constructed masterpiece of indirection and abstraction.
Obviously there are basic rules to follow, make it testable, don't mix too many concerns in one place but I see so much bikeshedding and overcomplicated code when it just needs to not be obviously wrong and easy to replace when needed.
All code we write is going to be wrong in some way as a result of our understanding of the problem domain being incomplete so I'd rather see code with an obvious place to put an if statement than a lovingly constructed masterpiece of indirection and abstraction.
Obviously there are basic rules to follow, make it testable, don't mix too many concerns in one place but I see so much bikeshedding and overcomplicated code when it just needs to not be obviously wrong and easy to replace when needed.
The code doesn't matter to the end user. Sure. You can say that about any industry. Engines don't matter as long as you can get from point A to point B and gas is cheap, which it isn't anymore. Healthcare norms don't matter when you are young and healthy. You can get away with this kind of reasoning in the short term. Engineering and almost any industry have rigorous codes and norms you have to follow, but not software engineering. Many software engineers are not engineers, but more like unlicensed plumbers or electricians that can fix the leak, and perhaps throw in a bunch of extension cords to make to hookup some electrician devices. Extension cords may work well for a while because they fix the customer problem, but long term may cause outages and fires. I think Software Engineering as a whole would benefit from more rigor. Of course, there has to be the right balance, as too much rigidity can hinder creativity and productivity, but saying that code doesn't matter is a wrong message.
This is true with basically everything. Game development attracts more than its fair share of truly horrid code, to the point where success seems almost inversely correlated to code quality. If you decompile Terraria (using CIL, which preserves the object design), for instance, you'll notice that its main class is over 40kLOC and that basically all of the business logic is encoded in one great big chain of if-statements. However, the game has been extremely popular and successful (and is pretty fast, and looks really pretty).
Somewhere there is a balance, but for business purposes it leans closer to the "working ugly hack" side.
Somewhere there is a balance, but for business purposes it leans closer to the "working ugly hack" side.
Maybe games can get away with more things because when they're done, they're (often) DONE.
There is no next release, maintenance, new features etc. Once Balloon Pirates is done it ships, and is never touched again.
There is no next release, maintenance, new features etc. Once Balloon Pirates is done it ships, and is never touched again.
I don't think that's been the case for a long, long time. Almost every new game on modern consoles and PCs will see one (or many) updates in its lifetime. Game cartridges, things we used to think of as immutable, are merely storage devices for delivery of the original game code. Two recent games I purchased for the Nintendo Switch, on cartridge, both required a download before I could play them.
It's more blurry but Games are still DONE in a way that an ongoing project where new features are constantly being added aren't. There are some exceptions like Minecraft but on average most games can not economically justify multiple full time engineers working on them for over a decade.
There is also the side issue of game engines which many teams reuse from game to game so maybe that doesn't really apply.
There is also the side issue of game engines which many teams reuse from game to game so maybe that doesn't really apply.
Terraria has been getting updates for 8 years now. Maybe that's why it's such a mess.
This is very far outside my realm of expertise but isn't it possible they're running some sort of obfuscation on the binary before releasing? 40k LOC seems unbelievable to me, surely even scrolling around in a text editor would be laggy as hell.
> all of the business logic is encoded in one great big chain of if-statements
One of the big lies of OO design is that you can manage that kind of complexity better with objects/classes, that you should factor out functionality into tiny pieces, and so on.
Unless you have written (and debugged!) an actual video game, you should spare your judgement.
One of the big lies of OO design is that you can manage that kind of complexity better with objects/classes, that you should factor out functionality into tiny pieces, and so on.
Unless you have written (and debugged!) an actual video game, you should spare your judgement.
There are certainly disadvantages. For a start, it keeps freezing my VS code :D
But Modders also have a hard time adding features if logic for all items is in a single function. This seemed exactly what OOP / interfaces were designed for.
Also I'd love to see Terraria's actual source code. The de-compiled versions hat a ton of stuff like
> if (num1 != 109 && num1 != 110 && (num1 != 113 && num1 != 115) && (num1 != 116 && num1 != 117 && num1 != 118)) return;
or
> else if ((int) Main.tile[i, j].type == 19) Type = 94;
20x in a row, with obviously different numbers. Hope the actual code was more readable and just lost a lot in translation. But many more readable styles should be visible in IL (enums, constants, etc). There might also have been some obfuscation (can't remember), but couldn't have a strong one since names were preserved.
But yes, there are also advantages to their style of code. And in the end they delivered a product and that's all that counts.
But Modders also have a hard time adding features if logic for all items is in a single function. This seemed exactly what OOP / interfaces were designed for.
Also I'd love to see Terraria's actual source code. The de-compiled versions hat a ton of stuff like
> if (num1 != 109 && num1 != 110 && (num1 != 113 && num1 != 115) && (num1 != 116 && num1 != 117 && num1 != 118)) return;
or
> else if ((int) Main.tile[i, j].type == 19) Type = 94;
20x in a row, with obviously different numbers. Hope the actual code was more readable and just lost a lot in translation. But many more readable styles should be visible in IL (enums, constants, etc). There might also have been some obfuscation (can't remember), but couldn't have a strong one since names were preserved.
But yes, there are also advantages to their style of code. And in the end they delivered a product and that's all that counts.
Exactly, having conditionals being spread throughout the program is a great way to increase complexity.
Rules engines, statecharts and other forms of (declarative) behaviour modelling solve real problems.
Rules engines, statecharts and other forms of (declarative) behaviour modelling solve real problems.
Then you have technical debt. Wordpress appeared good to end users, but we know how it is underneath and all the problem you get along[0]. It's a fine balance for sure, and forgetting that solving the problem first is what matters is a mistake indeed.
[0] about that, there seem to be a 'foot in the door' effect at play. If you get users with a good enough but imperfect product, they won't mind too much if you take responsibility for problems when they arise. Another instance of worse is better.
[0] about that, there seem to be a 'foot in the door' effect at play. If you get users with a good enough but imperfect product, they won't mind too much if you take responsibility for problems when they arise. Another instance of worse is better.
Wordpress is a great example. Its the most successful, most love blogging platform and usually user's first choice.
Man, I cannot deny and submit to the reality of wordpress dominance. That said have you ever poked at wordpress plugins code ? I won't name the one I read but it was a catastrophy. And not in a pedantic purist sense, real catastrophy, dead code everywhere, while loops 8 screens long, copy pasted above each others. I think it was #2 most downloaded at the time.
The code is crap. Wordpress is crap. It's unsafe, open-to-hackers crap. The plugins are crap.
But it solves the problem users want solved. It's lego-level blog assembly, which is as technical as many users want to get. A much "better" system - maybe a nice type-safe Haskell static HTML templater with a command line build system - wouldn't.
Flipping this around, from the user's POV, "I wrote some code that almost does Thing X" is not a solution - it's just some code that doesn't quite do the job.
It's nice that it uses functional programming or formal methods or $shiny_language or ML or whatever. But if it doesn't do the job, it doesn't solve the problem.
But it solves the problem users want solved. It's lego-level blog assembly, which is as technical as many users want to get. A much "better" system - maybe a nice type-safe Haskell static HTML templater with a command line build system - wouldn't.
Flipping this around, from the user's POV, "I wrote some code that almost does Thing X" is not a solution - it's just some code that doesn't quite do the job.
It's nice that it uses functional programming or formal methods or $shiny_language or ML or whatever. But if it doesn't do the job, it doesn't solve the problem.
I don't agree with the analysis. It's mostly that mainstream life floats on ambiguity and undefined contexts. Wordpress does some things perfect for users but then bug or leak or plugin conflicts happen. While other platform may have solved this prior but it's a problem that users didn't anticipate so they didn't value it.
and globals. mutable globals everywhere. (at least last time i ran away from it all after having to fix an EOL'd plugin 10 years ago).
never again.
never again.
Why don't they fix it? It's long lived, it's popular, they have to maintain it.
Yes, there's backwards compatibility to maintain, but surely some of it can be contained, maybe with shims, like Windows does it.
Yes, there's backwards compatibility to maintain, but surely some of it can be contained, maybe with shims, like Windows does it.
Why don't they fix it?
In all likelihood, because the people maintaining Wordpress are the people who created it in the first place, and they don't know any better.
Why did PHP apps suffer from SQL injection attacks, long after PHP supported prepared statements? Why do Java apps often have ridiculous classes like AbstractSingletonThingFactoryFactory? Why does the Javascript community (still) promulgate useless leftpad-like packages? Why do Ruby apps often end up so heavily metaprogrammed that you can't trust any line of code to do what it says?
Cultures are hard to change. The people that are turned off by Wordpress' programming style probably pick other projects and other communities. Lots of the folks working on Wordpress probably cut their teeth in that codebase. They might not like it and they might realize there are better ways, but there probably isn't a critical mass of them that share a vision out of the morass.
Personally, I took one brief look under the covers of Wordpress and immediately decided to avoid it.
In all likelihood, because the people maintaining Wordpress are the people who created it in the first place, and they don't know any better.
Why did PHP apps suffer from SQL injection attacks, long after PHP supported prepared statements? Why do Java apps often have ridiculous classes like AbstractSingletonThingFactoryFactory? Why does the Javascript community (still) promulgate useless leftpad-like packages? Why do Ruby apps often end up so heavily metaprogrammed that you can't trust any line of code to do what it says?
Cultures are hard to change. The people that are turned off by Wordpress' programming style probably pick other projects and other communities. Lots of the folks working on Wordpress probably cut their teeth in that codebase. They might not like it and they might realize there are better ways, but there probably isn't a critical mass of them that share a vision out of the morass.
Personally, I took one brief look under the covers of Wordpress and immediately decided to avoid it.
Maybe a 'if it aint broke dont fix it' paired with 'lets make this new feature instead'.
There's such a thing as taking the backwards compatibility meme too far though. You can't keep catering to those that drag their feet. Release an update and say that the legacy will no longer be supported a year from now.
For better or worse:
https://old.reddit.com/r/webdev/comments/bx51vk/we_need_to_t...
https://old.reddit.com/r/webdev/comments/bx51vk/we_need_to_t...
Ugh. The submitter there uses Some of you guys are killing people figuratively. Are they not aware that bad software really does kill people?
I was expecting to see some ill-advised use of WordPress in a critical software system, but no, it's about inconveniencing web developers. </rant>
I was expecting to see some ill-advised use of WordPress in a critical software system, but no, it's about inconveniencing web developers. </rant>
Debt (technical and otherwise) is leverage if utilized well, and potentially crippling if abused.
I knew a shop that refused to move its customer data out of an ancient MS Access instance until one day it just started shedding records.
That's what I think of when I hear technical debt.
What are examples that make sense and don't just explode in your face?
That's what I think of when I hear technical debt.
What are examples that make sense and don't just explode in your face?
Whatever it is you're writing doesn't have to work for the next twenty years. If it's sufficiently simpler and cheaper, it's fine if that project only works for the next five years, and you have to start working on a rewrite in four. By then, you'll either have gone broke (in which case the extra scaling would've been useless anyhow), or you'll have four more years of experience to guide you in how to build the next generation.
In your particular case, that MS Access DB was almost certainly the right choice when it was written, and the gotcha in that story is that they didn't start planning the migration away from Access until it was too late — effectively, they didn't pay off the tech debt when they should have, and got foreclosed on.
In your particular case, that MS Access DB was almost certainly the right choice when it was written, and the gotcha in that story is that they didn't start planning the migration away from Access until it was too late — effectively, they didn't pay off the tech debt when they should have, and got foreclosed on.
[deleted]
An example of really bad technical debt we made in one of our projects was: back when Facebook apps were a thing, another social networking site released an app platform that was very similar to Facebook. Some companies had early partnership and launched at release, but we weren't aware of it and were caught flat footed.
Our code wasn't built to be generic enough to be able to work on anything but Facebook. So what we did was simple: copy the whole project, change the stuff that didn't work right.
The next time a social networking site released a platform we refactored our main code and introduced the proper abstractions so we could use it on all 3 sites. That code ended up working for most of the other social networks that launched an app platform.
Our code wasn't built to be generic enough to be able to work on anything but Facebook. So what we did was simple: copy the whole project, change the stuff that didn't work right.
The next time a social networking site released a platform we refactored our main code and introduced the proper abstractions so we could use it on all 3 sites. That code ended up working for most of the other social networks that launched an app platform.
I'll use your example: I've seen companies start life as Access databases and make plenty of money, and then pay for the proper rewrite out of the revenues generated, instead of doing it the "right way" up front. (when the costs to do it up front may have resulted in a failure to launch)
I don't think it's the type of debt that's the issue, as much as how you manage it.
I don't think it's the type of debt that's the issue, as much as how you manage it.
I think part of the problem is that humans are fundamentally present-biased. So low quality code that can avoid a schedule delay today is considered preferable to higher quality code that prevents even larger schedule delays in the future.
> Another instance of worse is better.
I hate this term, because worse isn't better, it's worse. But good enough is good enough and technically-better-but-not-available-yet is worse than adequate-and-available-right-now.
I hate this term, because worse isn't better, it's worse. But good enough is good enough and technically-better-but-not-available-yet is worse than adequate-and-available-right-now.
Uh, the code does matter in almost all circumstances. That's because in most cases you're not so much solving something unsolved as providing a lower cost solution via software. The cost of the software (both in terms of initial development and ongoing maintenance) is a factor.
If your problem domain is totally mapped out, maybe any solution that is quick to implement will work. If your problem domain is in any way nebulous or changing, well architected software will save you a lot of money responding to changes, and ongoing maintenance will obviously be cheaper if it's easily testable and robust.
If your problem domain is totally mapped out, maybe any solution that is quick to implement will work. If your problem domain is in any way nebulous or changing, well architected software will save you a lot of money responding to changes, and ongoing maintenance will obviously be cheaper if it's easily testable and robust.
I think the parent's point (though I could be reading my own thoughts into it), is that the things you mention only matter to the user if it directly affects them. An end user couldn't care less what the maintenance costs are if they aren't passed on to them in some way. If they are, then its completely in the interests of the company to have easy to maintain software. Or if changes are time-sensitive and the company is unable to keep up which change requests. If all that's invisible to "users" (or internal stakeholders), it really doesn't matter how much the boots on the ground hate the software.
But I think also the "code doesn't matter" really means, that ideally there is no (new) code, because there is in fact an existing solution but the person asking for the solution doesn't know it. This is likely more the case with internal stakeholders that ask for something to be built that does X, not realizing that there is readily available software or libraries that does X (or something close to it). So part of our role is to know the landscape of what part of the domain really needs new (potentially bug-ridden code) to be written.
But I think also the "code doesn't matter" really means, that ideally there is no (new) code, because there is in fact an existing solution but the person asking for the solution doesn't know it. This is likely more the case with internal stakeholders that ask for something to be built that does X, not realizing that there is readily available software or libraries that does X (or something close to it). So part of our role is to know the landscape of what part of the domain really needs new (potentially bug-ridden code) to be written.
This realization is what has attracted me to the Erlang/Elixir world where fault tolerance > provable correctness.
The end user would rather have an application be frantically logging errors in the background, but be working for their usecase, than a program that is fixated with being correct and refusing to run in the presence of errors.
Obviously quality code still matters, but at least in the business realm "does it do what I expect?" is basically your success/fail state.
The end user would rather have an application be frantically logging errors in the background, but be working for their usecase, than a program that is fixated with being correct and refusing to run in the presence of errors.
Obviously quality code still matters, but at least in the business realm "does it do what I expect?" is basically your success/fail state.
This bothers me. As code continues to eat the world, this is akin to saying “building codes don’t matter”. That is dangerous. And it isn’t professional.
Experienced developers know when to spend time making sure code is actually good and when a terrible crufty hack is fine. If you think "All code must be perfect" then you're not a pro yet.
>If you think "All code must be perfect" then you're not a pro yet
Or they're a pro in a very different field than you.
When I worked in web development, I was gobsmacked at what professionals considered "good enough to ship". Now that I work in Medical EHR, the standards for 'good enough to ship' when lives could be on the line is very, very, very different.
I imagine a NASA engineer creating famously low-defect code or perhaps an engineer creating control systems for a nuclear power plant would similarly look at our medical code and think we too ship far too many hacks and defects.
Or they're a pro in a very different field than you.
When I worked in web development, I was gobsmacked at what professionals considered "good enough to ship". Now that I work in Medical EHR, the standards for 'good enough to ship' when lives could be on the line is very, very, very different.
I imagine a NASA engineer creating famously low-defect code or perhaps an engineer creating control systems for a nuclear power plant would similarly look at our medical code and think we too ship far too many hacks and defects.
People in fields where they write code that has to be proven can still know when it's appropriate to write bad hacky code. If they believe "I write proven code for my EHR system therefore all code must be like that." I would argue they're not pros.
Being a professional is knowing how to do your job well. Applying a single heuristic to every problem isn't that.
Being a professional is knowing how to do your job well. Applying a single heuristic to every problem isn't that.
> If you think "All code must be perfect" then you're not a pro yet.
> Applying a single heuristic to every problem isn't that.
How ironic :)
> Applying a single heuristic to every problem isn't that.
How ironic :)
I'm surprised this hasn't come up yet, but the following should be required reading. I don't want to invoke "we follow orders or people die" (or blow up), but...
https://www.fastcompany.com/28121/they-write-right-stuff
https://en.wikipedia.org/wiki/Therac-25
https://www.fastcompany.com/28121/they-write-right-stuff
https://en.wikipedia.org/wiki/Therac-25
[deleted]
[deleted]
That's the point. The context of the code matters. 99% of code is not critical to life. Applying NASA level of rigor to every line of code ever written is an indication of mental disorder (autistic obsession)
I never, ever, said “All code must be beautiful. I never even implied it. Unless there is some general agreement that I am unaware of among architects and builders that building codes exist to make building plans “beautiful”.
And about that implied ad hominem. It doesn’t matter if I’m a pro.
Building codes allow one to say whether plans conform or do not conform to code. That way you don’t have to be a “pro” to determine whether the plan is up to code. You compare the plan to the code. You didn’t write the code. You don’t need to think the code describes beautiful plans. You just compare.
And about that implied ad hominem. It doesn’t matter if I’m a pro.
Building codes allow one to say whether plans conform or do not conform to code. That way you don’t have to be a “pro” to determine whether the plan is up to code. You compare the plan to the code. You didn’t write the code. You don’t need to think the code describes beautiful plans. You just compare.
And often business owners won't allow you to make that determination alone.
Like in any business area. But in the end, it's their business and their responsibility.
"code doesn't matter" is more like "code beauty doesn't matter", in the same way that beautiful foundations for a building do not matter (or are incidental) to its stability.
Quality matters.
There is quality in code which you seem to be ignoring, troubling.
There is quality in delivering on time.
There is quality in the end-users' experience.
There is quality in the developers' experience.
There is quality in the investors' experience.
Quality is different than maximizing a metric (earnings per share, on time deliveries, user experience survey score, code coverage)
There is quality in finding the right balance in any situation.
Many many people want to maximize a single metric tacitly expecting everything else to be great, that is a good lesson to unlearn. Switching from one quality target to another is not.
There is quality in code which you seem to be ignoring, troubling.
There is quality in delivering on time.
There is quality in the end-users' experience.
There is quality in the developers' experience.
There is quality in the investors' experience.
Quality is different than maximizing a metric (earnings per share, on time deliveries, user experience survey score, code coverage)
There is quality in finding the right balance in any situation.
Many many people want to maximize a single metric tacitly expecting everything else to be great, that is a good lesson to unlearn. Switching from one quality target to another is not.
A corollary to this is: the code should match the problem domain.
If the business problem is complicated, trying to further simplify the code usually makes it awkwardly abstracted and extra brittle. The fix should not be _just_ cleaning up the code, but rather trying to resolve the original usecase.
If the business problem is complicated, trying to further simplify the code usually makes it awkwardly abstracted and extra brittle. The fix should not be _just_ cleaning up the code, but rather trying to resolve the original usecase.
Hah I got the exact opposite realization actually.
Yes if you boil it down to it’s essentials you are right the customer is the one with the money, so satisfying his needs/desires is what matters.
But, and thats a big but, we as devs are also humans, we also have desires and needs, and in the long run companies that successfully balance the needs of its users with the needs of its workforce get the best workers, which solve the problems of their users better/cheaper/faster.
So it’s more of an equilibrium kinda thing. If you stray too much in any direction the organization tanks - either the users loose faith, or the people satisfying theirs needs do, which leads to failure just as much.
The complexity with balancing this usually stems from the fact that both of those variables are subjective to their respective environment - users can tolerate bad solutions if there are no alternatives available, same with devs.
And that is also a subject to information availability - devs can be ok with their situation because they don’t know what salaries are at that other place for example.
Yes if you boil it down to it’s essentials you are right the customer is the one with the money, so satisfying his needs/desires is what matters.
But, and thats a big but, we as devs are also humans, we also have desires and needs, and in the long run companies that successfully balance the needs of its users with the needs of its workforce get the best workers, which solve the problems of their users better/cheaper/faster.
So it’s more of an equilibrium kinda thing. If you stray too much in any direction the organization tanks - either the users loose faith, or the people satisfying theirs needs do, which leads to failure just as much.
The complexity with balancing this usually stems from the fact that both of those variables are subjective to their respective environment - users can tolerate bad solutions if there are no alternatives available, same with devs.
And that is also a subject to information availability - devs can be ok with their situation because they don’t know what salaries are at that other place for example.
After 15 years in the business I think it’s worse than that: code is a liability. It matters - to have as little of it as necessary and not a line more.
Nope. Sometimes it's the right choice to leave something in that your heuristic would lead you to rip out.
Can we stop with these simplistic maxims? Engineering is about tradeoffs and dealing with complexity. Trying to reduce the decision-making process to a single sentence is silly.
Can we stop with these simplistic maxims? Engineering is about tradeoffs and dealing with complexity. Trying to reduce the decision-making process to a single sentence is silly.
True. Oh man, I was so angry about that. You read all them books, refactor anything, use that functional programming, but in the end: who cares! A shiny new button gets more attention than you refactoring that SQL statement.
If you get away from frontend fluff and work on serious backend systems involving large financial transactions, they will appreciate those more advanced engineering skills and disciplines.
Perfecto! As a programmer turned product manager, I see this first hand every single day. The end user doesn’t care what technology you use as long as it solves their problem(s). My managers don’t care what technology my team uses as long as timelines and budgets are met. I’m astonished and sometimes smile at how my old programmer self wouldn’t understand this basic fact.
You're right that the end user doesn't care about what technology you use, but do they care about things not working? Do they care that a new feature takes 3 months to develop when it could have taken 1 month if the code had been better architected?
Its funny to see management types dismiss the programmers as being "airy-fairy" when they talk about things like code quality and technology stacks but then they wonder why things get completed on time, why bugs happen, why sites get hacked etc.
Somebody else has mentioned this analogy before in this thread, but if you had a house built would you say the same thing about the structural integrity? "As long as the floor can support me then thats all that matters", "House dwellers don't care what kind of structural beams are used to support the floor they just want it to not collapse". That kind of a mentality is ok for an average person living in a house but you'd you have to be off your rocker to hire a building manager who said that.
Its funny to see management types dismiss the programmers as being "airy-fairy" when they talk about things like code quality and technology stacks but then they wonder why things get completed on time, why bugs happen, why sites get hacked etc.
Somebody else has mentioned this analogy before in this thread, but if you had a house built would you say the same thing about the structural integrity? "As long as the floor can support me then thats all that matters", "House dwellers don't care what kind of structural beams are used to support the floor they just want it to not collapse". That kind of a mentality is ok for an average person living in a house but you'd you have to be off your rocker to hire a building manager who said that.
My bad if I gave you the wrong impression about management types. You're right that things should work. What I meant was this: assume you have technology stack A and B each with its own pros and cons (whether tech maturity, programmer skills or what have you). Then, higher management expects the lead programmer/engineering manager to review the pros and cons and take the decision and deliver keeping the end user in mind. Whether stack A has xyz features which will do blah-blah-blah to the team is less relevant than the deliverable. Hope it is clear :-)
I think I get your point. As someone who doesn’t have any particular specialty (I do webdev, “embedded” devices, image processing, tooling, design, etc.), I always hesitate when someone asks me what I do. I consider the things I can do as tools to get something done.
I interned at a research facility where I had to figured out obscure serial commands for a two axis objective stage, interface microscope camera, and image analysis. Then I wrapped it all in a python library for them to use.
From my mentors perspective however, the goal was “simple”: you find a microorganism swimming under microscope, and keep following it to record its trajectory. Make sure each tick is max 10ms because those little ones move FAST. They didn’t care if I used 4 space indents or 2. They cared about getting pandas dataframe so they could do all the analysis.
I can’t explain this in a word or few, and I still don’t know what to call myself! Am I a developer? I don’t know.
I interned at a research facility where I had to figured out obscure serial commands for a two axis objective stage, interface microscope camera, and image analysis. Then I wrapped it all in a python library for them to use.
From my mentors perspective however, the goal was “simple”: you find a microorganism swimming under microscope, and keep following it to record its trajectory. Make sure each tick is max 10ms because those little ones move FAST. They didn’t care if I used 4 space indents or 2. They cared about getting pandas dataframe so they could do all the analysis.
I can’t explain this in a word or few, and I still don’t know what to call myself! Am I a developer? I don’t know.
> Am I a developer? I don’t know.
I would say the title "Research Engineer" could fit quite well based on what you describe!
I would say the title "Research Engineer" could fit quite well based on what you describe!
> the code doesn't matter
It does if you want someone other than the person who wrote it to be able to fix bugs and add features.
It does if you want someone other than the person who wrote it to be able to fix bugs and add features.
I agree with you but I can't bear to say code doesn't matter. Try not writing any and see how valuable software is without it. Better yet, delete it and see what happens :D. I expect Codeless will become a thing one day but, until that day comes you will write code, because the code is necessary and I have trouble saying that the code is needed but also doesn't matter. Least important necessity maybe?
I've read on this website about people launching minimum viable products that appear to the customer to be some kind of automated service that in reality are the owner manually satisfying the order.
The software isn't necessarily what the customer values. You can provide a valuable service with 0 LOC
The software isn't necessarily what the customer values. You can provide a valuable service with 0 LOC
What tool makes them, and what's the tool made out of? You go back far enough, someone had to write code for something. You're not wrong though but it sounds like a domain specific thing too. Vending Machine as a service essentially. Still, as long as people are writing code it'll be because there's no choice but to write it for their use case.
I call this the intrinsic quality of the code. As you say, it isn't that it does not matter at all, just that it is over indexed by many of us.
> To the end user, what matters is that we solve their problem. We let them do their job, and we make that job as easy as possible. And that's what they pay us for.
If your code quality is bad, you can't do that efficiently. Your developers will hate their jobs and churn like crazy.
And by "bad quality" I don't mean "not unit tested" or "not commented" or "poorly formatted". I'm talking about code that is difficult to reason about, difficult to debug and difficult to refactor or extend. This is hard to quantify or even verbalize. It has to be felt.
If your code quality is bad, you can't do that efficiently. Your developers will hate their jobs and churn like crazy.
And by "bad quality" I don't mean "not unit tested" or "not commented" or "poorly formatted". I'm talking about code that is difficult to reason about, difficult to debug and difficult to refactor or extend. This is hard to quantify or even verbalize. It has to be felt.
And the business will feel it eventually. Developers have this magical ability to create invisible time-delayed catastrophes.
Overall a good article, but I completely disagree with the notion that "good enough is good enough".
I've been in a lot of code reviews where developers push back because it's "good enough". You need to maintain a defined level of quality otherwise codebases go to shit very, very fast.
I was recently told in a code review that a Cassandra read before a write (to ensure there were no duplicates) was "good enough" because a duplicate "probably wouldn't happen very often". Meanwhile, the consequences of a dupe would lead to a pretty bad customer experience.
I pushed back hard and forced the developer to rewrite his entire code. Would "good enough" be okay in this situation? My bar is much higher than this developer and I stand by my decision. We have the luxury of being tasked with solving customer problems and if we only strive for "good enough" every time instead of "the best I can do within the constraints I'm given", then in my opinion your career won't be very successful. We always have to make the best tradeoffs when it comes to time and expense, but the best developers are the ones that come up with the best solution and the best code that fits in a particular constraint.
I've been in a lot of code reviews where developers push back because it's "good enough". You need to maintain a defined level of quality otherwise codebases go to shit very, very fast.
I was recently told in a code review that a Cassandra read before a write (to ensure there were no duplicates) was "good enough" because a duplicate "probably wouldn't happen very often". Meanwhile, the consequences of a dupe would lead to a pretty bad customer experience.
I pushed back hard and forced the developer to rewrite his entire code. Would "good enough" be okay in this situation? My bar is much higher than this developer and I stand by my decision. We have the luxury of being tasked with solving customer problems and if we only strive for "good enough" every time instead of "the best I can do within the constraints I'm given", then in my opinion your career won't be very successful. We always have to make the best tradeoffs when it comes to time and expense, but the best developers are the ones that come up with the best solution and the best code that fits in a particular constraint.
Hey! OP here. I definitely don't mean "good enough is good enough" as an excuse -- pushing for quality is extremely important.
My point was more about nitpicking line by line for perfection. What you're talking about sounds like a legitimate performance issue.
I think we're on the same page, but maybe my point wasn't clear enough. I tried to make it clear in my last point that "code is quality is important" but it's important not to confuse code quality with things that are more minor like idiosyncratic coding style.
Thanks for reading!
My point was more about nitpicking line by line for perfection. What you're talking about sounds like a legitimate performance issue.
I think we're on the same page, but maybe my point wasn't clear enough. I tried to make it clear in my last point that "code is quality is important" but it's important not to confuse code quality with things that are more minor like idiosyncratic coding style.
Thanks for reading!
When I code review, I differentiate between "code quality" and "opinion". First off, there needs to be a coding standard guideline so that 80% of all issues of "opinion" vs "coding standard" are well defined. This is one of the reasons why I like go, because things like go fmt are the great equalizer.
I probably won't like the variable names people chose but I won't comment on that because that's "my opinion". I will comment on even the smallest bug I see, because that's what we're paid to do. So line by line "perfection" is what I believe we need to strive for in terms of code quality. Maybe not so much "perfection" but "best practices" might be a better way of stating it. We always need to strive for best practices so that our code is predictably easy to maintain, read, etc.
I probably won't like the variable names people chose but I won't comment on that because that's "my opinion". I will comment on even the smallest bug I see, because that's what we're paid to do. So line by line "perfection" is what I believe we need to strive for in terms of code quality. Maybe not so much "perfection" but "best practices" might be a better way of stating it. We always need to strive for best practices so that our code is predictably easy to maintain, read, etc.
Agree with this. I obviously comment on bugs and also convoluted code that I know will be hard to understand later. If it is just small details it is easier to just change them myself when I inevitably have to revisit the code later on rather than nitpicking and arguing during the review. If I don't have to revisit the code for any change then just let it be. Out of sight, out of mind
Another way to skin this cat I'd say is that the definition of "perfection" or "best practices" is different depending on the use-case, company, product, or mission. Making sure you have a very clear definition of quality and "done-ness" is really important here. For some products any bug is a no-go. For others, lots of small visual bugs are ok, and on and on. But once you agree on that definition of quality, I totally agree with you that everyone needs to champion that definition.
I'm going to challenge you here (admittedly without full context, but to make a point). It sounds to me like the problem you're describing requires a database has ACID transactions which is not Cassandra. Therefore Cassandra is a poor choice and in my view that is poor engineering. This being said, I'd err on the side of agreeing with the developer who determined that they are not capable of writing code that guarantees ACID transactions in Casandra (that's a hard thing to do), and I'd really question the choice to use it to begin with.
Again without appropriate context, my bet here is that you guys are using Cassandra for other important features you won't get out of a typical RDBMS and as such you made a trade off to begin with and decided that Cassandra was "good enough".
Now the point I'm trying to illustrate (and I'm not just doing this to pick a fight, I promise), is that engineering is about trade offs and a big part of it is definitely related to likelihood of a problem occurring.
I think it also completely depends on the domain of the problem, the criticality of the process you're building and the outcome of a major failure of your assumptions.
So I'd just argue and say "good enough" is an entirely appropriate answer in many contexts and domains and it's important not to make a blanket assumption that it's wrong.
Again without appropriate context, my bet here is that you guys are using Cassandra for other important features you won't get out of a typical RDBMS and as such you made a trade off to begin with and decided that Cassandra was "good enough".
Now the point I'm trying to illustrate (and I'm not just doing this to pick a fight, I promise), is that engineering is about trade offs and a big part of it is definitely related to likelihood of a problem occurring.
I think it also completely depends on the domain of the problem, the criticality of the process you're building and the outcome of a major failure of your assumptions.
So I'd just argue and say "good enough" is an entirely appropriate answer in many contexts and domains and it's important not to make a blanket assumption that it's wrong.
We aren't in disagreement, and I don't take your comment as a challenge, it was exactly something we went through with this feature. The point is, who gets to decide what "good enough" is? The difference between my "good enough" is a lot different than my coworker's "good enough", and I think that's what separates levels of maturity as a developer.
In fact Cassandra wasn't my first choice, but a strongly consistent database wasn't available to us. As I mentioned in another comment, making the very best decision you can given the constraints of your system is what one should strive for. Not stopping at "good enough" because of (poor) intuition that error conditions "probably won't happen".
We decided to go with LWT and eat the latency costs as a trade off to "stronger" consistency, realizing that Cassandra doesn't offer the same strong consistency as an ACID database. Not perfect, but it fit within our SLA, decreased the probability of encountering duplicate values, and if there was an error, it was easier to detect and the user could be directed to try again, vs having a completely silent error condition that would cause a small percentage of our users tremendous amounts of trouble.
In fact Cassandra wasn't my first choice, but a strongly consistent database wasn't available to us. As I mentioned in another comment, making the very best decision you can given the constraints of your system is what one should strive for. Not stopping at "good enough" because of (poor) intuition that error conditions "probably won't happen".
We decided to go with LWT and eat the latency costs as a trade off to "stronger" consistency, realizing that Cassandra doesn't offer the same strong consistency as an ACID database. Not perfect, but it fit within our SLA, decreased the probability of encountering duplicate values, and if there was an error, it was easier to detect and the user could be directed to try again, vs having a completely silent error condition that would cause a small percentage of our users tremendous amounts of trouble.
That was my thought, too. If you need ACID transactions, use an ACID database. There are rather a lot of them. And then mirror the data out to Cassandra after the fact, if you need it there. Ironically, Cassandra may not be the source of truth!
Way back in the stone age, MySQL did not yet have ACID transactions. They got them about the same time they stopped bragging about how much faster they were than Oracle, but I digress. Anyway, I had to write a bunch of transactional code around it. Drove the dba and me nuts. We begged for Sybase (we both knew it well), but the startup CTO was an open source purist and hated his first contact with the Sybase sales machine.
Eventually they folded, and the point was moot.
Way back in the stone age, MySQL did not yet have ACID transactions. They got them about the same time they stopped bragging about how much faster they were than Oracle, but I digress. Anyway, I had to write a bunch of transactional code around it. Drove the dba and me nuts. We begged for Sybase (we both knew it well), but the startup CTO was an open source purist and hated his first contact with the Sybase sales machine.
Eventually they folded, and the point was moot.
> You need to maintain a defined level of quality otherwise codebases go to shit very, very fast.
And it's that level that we call "good enough". Or, I would say, acceptably bad.
One of the most important lessons I've learnt over my career is that there is no such thing as "good" software. Everything could always suck less — anything that takes over 0.0 seconds is bad, more than 0kB of memory is bad, more than 0 lines of code is bad. However, your level of badness for each of these metrics might be something you're willing to live with.
It's like hygiene. What you call "nice and clean" for your toilet is not clean enough that you'd cook on it, and even your "immaculate" kitchen is unacceptable for, say, an OR. Hygiene is always "bad", you're just looking for a point where it's no longer unacceptably bad for your purpose.
And it's that level that we call "good enough". Or, I would say, acceptably bad.
One of the most important lessons I've learnt over my career is that there is no such thing as "good" software. Everything could always suck less — anything that takes over 0.0 seconds is bad, more than 0kB of memory is bad, more than 0 lines of code is bad. However, your level of badness for each of these metrics might be something you're willing to live with.
It's like hygiene. What you call "nice and clean" for your toilet is not clean enough that you'd cook on it, and even your "immaculate" kitchen is unacceptable for, say, an OR. Hygiene is always "bad", you're just looking for a point where it's no longer unacceptably bad for your purpose.
Codebases all go to shit pretty fast. That is really what you learn as a senior developer. The fully sustainable codebase is a myth. All codebases will inevitably get progressive more difficult to work on no matter what you or anyone else does.
All software eventually gets rewritten. Either in full or in parts. So "good enough" means "will this keep it going until this software, or piece of this software, is thrown away and replaced". Because that is typically much more economical than code review infighting causes 2-4 rewites of every feature until its perfect. Or spending 3 times more time on a feature to make it perfect. Or having to hire very expensive developers that are capable of writing to that high standard.
There are obvious exceptions in specific industries, but this holds true for 80%.
All software eventually gets rewritten. Either in full or in parts. So "good enough" means "will this keep it going until this software, or piece of this software, is thrown away and replaced". Because that is typically much more economical than code review infighting causes 2-4 rewites of every feature until its perfect. Or spending 3 times more time on a feature to make it perfect. Or having to hire very expensive developers that are capable of writing to that high standard.
There are obvious exceptions in specific industries, but this holds true for 80%.
I have experienced great difficulties with literal spaghetti code written in delphi which one can only follow through debugging, but I have also seen large codebases written in kotlin and python where almost everything is in layers and it is obvious where to add a new feature and how to find one that doesn't work. And I was very afraid that the project would end up an entangled mess, but luckily, it had the right mixture of individual services (for scaling), monoliths and messaging mediums to not become a mess.
I understand what you are saying. I think what she's really referring to is: The perfect is the enemy of the good. You have to adhere to certain level of standards, but at some point you do have to admit there is a difference between, "this has problems", and "it's not how I would have done it, but it works and is more or less OK."
Good enough is by definition, good enough.
It's up to the team and customers to decide on that however. Database integrity is particularly important, so with limited information, I'd say you made the right decision. Therefore the first draft of the code was not good enough.
So, we should all be in agreement now, right?
It's up to the team and customers to decide on that however. Database integrity is particularly important, so with limited information, I'd say you made the right decision. Therefore the first draft of the code was not good enough.
So, we should all be in agreement now, right?
Right, but who decides what "good enough" is? If I weren't code reviewing, then it would have passed as "good enough". And that's the point of why just saying good enough isn't good enough. There should be a threshold that no one fights over.
He gave the threshold in his comment though.
> It's up to the team and customers to decide on that however.
You said yourself:
>the consequences of a dupe would lead to a pretty bad customer experience.
I've seen many situation were a duplicate wouldn't matter to a customer. It would matter to me because like you, I'm a perfectionist, but at the end of the day, it's both the team and customers that decide together.
> It's up to the team and customers to decide on that however.
You said yourself:
>the consequences of a dupe would lead to a pretty bad customer experience.
I've seen many situation were a duplicate wouldn't matter to a customer. It would matter to me because like you, I'm a perfectionist, but at the end of the day, it's both the team and customers that decide together.
It's also a matter of dealing with the problem now while it's right in front of your eyes and you remember.
Generalizing here but assume 6 months later this rare duplicate happens for a very important customer so you can't just brush it off, you now really have to fix it. By then nobody remembers this code review so you don't even know if this duplicate is a one off rare event or if it is going to affect all customers. Fixing it in code review might have taken a few hours extra for one guy, now you sent the whole team scrambling weekend overtime just to find the issue and understand the implications.
Generalizing here but assume 6 months later this rare duplicate happens for a very important customer so you can't just brush it off, you now really have to fix it. By then nobody remembers this code review so you don't even know if this duplicate is a one off rare event or if it is going to affect all customers. Fixing it in code review might have taken a few hours extra for one guy, now you sent the whole team scrambling weekend overtime just to find the issue and understand the implications.
> "good enough" because a duplicate "probably wouldn't happen very often". Meanwhile, the consequences of a dupe would lead to a pretty bad customer experience. [...] My bar is much higher than this developer...
I see a lot of posturing in this anecdote, what I think is missing are:
1 - an indication of how often would a customer experience the issue;
2 - how bad would his "bad experience" be;
Did you calculate the former and took in account the latter in forming your judgement?
Or, otherwise, was the "correct" solution simple and obvious enough that any non-junior developer would have picked that first without hesitation?
I see a lot of posturing in this anecdote, what I think is missing are:
1 - an indication of how often would a customer experience the issue;
2 - how bad would his "bad experience" be;
Did you calculate the former and took in account the latter in forming your judgement?
Or, otherwise, was the "correct" solution simple and obvious enough that any non-junior developer would have picked that first without hesitation?
You're getting some flack because "good enough" is too loaded and everyone reads it a little differently. No one seems to be reading your qualifier, "the consequences of a dupe would lead to a pretty bad customer experience."
Sometimes, good enough is good enough. If you were able to push back hard in this case, I take it you are senior to the other guy and your decision is/was justified by the product/feature requirements. IOW, in this case, good enough was in fact not good enough.
> constraint
most important thing, right there.
Sometimes, good enough is good enough. If you were able to push back hard in this case, I take it you are senior to the other guy and your decision is/was justified by the product/feature requirements. IOW, in this case, good enough was in fact not good enough.
> constraint
most important thing, right there.
I don't think anybody would argue pushing bugs is good enough or qualifies as such under any circumstance. I think good enough means that no codebase is perfect and working with nitpicky perfect types is the absolute worst IMO. Not only that, I've seen those codebases too and they are often times just as convoluted and messy, although without trailing whitespace and no missing semicolons.
There's the "it'll do" mean of "good enough", which really isn't good enough. Then there's the "of sufficient quality" meaning, which is by definition good enough. The latter is the true minimum bar, IMO, and what I believe the author means?
I also think that a blatant disregard for correctness is not good enough. For me the good enough is more around style and architecture. If there’s an obvious bug, even if it only affects .1% of users it should be fixed. After all, if you have a million users your bug now affects 1,000 people.
[deleted]
Well, it's very clear that what the developer was trying to do was not "good enough."
> So imagine my surprise when I showed up at my first day on the job at a startup and found no tests at all. No tests in the frontend. No tests in the backend. Just, no tests.
That one hits home. I felt like I was being so helpful when I, fresh-eyed after finishing some entry-level C language book, suggested that we should implement unit tests to the legacy software.
The product lead, to his credit, did not chew me out, but stated very reasonably, "This software is old, relatively stable, and will likely be dead or sunset in five years. It's not worth the man-hours it would take to try retrofitting unit tests onto a piece of software this old, only for the product to be killed six months after we finish writing them."
That one hits home. I felt like I was being so helpful when I, fresh-eyed after finishing some entry-level C language book, suggested that we should implement unit tests to the legacy software.
The product lead, to his credit, did not chew me out, but stated very reasonably, "This software is old, relatively stable, and will likely be dead or sunset in five years. It's not worth the man-hours it would take to try retrofitting unit tests onto a piece of software this old, only for the product to be killed six months after we finish writing them."
Tests are a really important part of development. There's nothing wrong with suggesting tests. The wrong thing is to insist on it to the point it creates a conflict with you and your team. Either set an example and write tests and see if it creates value and your team is OK with it, make a convincing argument or if you think tests are needed very badly because everything is broken all the time and you can't convince anyone, get a new job. Sticking around and being bitter about it is the thing that's bad.
I usually ask upfront in an interview if the team writes tests and if they don't and I get the idea they don't want to I probably wouldn't work there.
I usually ask upfront in an interview if the team writes tests and if they don't and I get the idea they don't want to I probably wouldn't work there.
My Absolute truth I unlearned as a Senior developer. your knowledge, hard work and quality of work is not important. The relationship that you have with your boss and your bank account is what you need to focus on.
> your knowledge, hard work and quality of work is not important.
Bingo. I used to be that guy who'd spend my weekends fixing the code that everyone else left messed up on Friday or at the bookstore reading up on the latest framework. And I thought that someday it would be recognized with promotions or more pay or even a pat on the back.
Nope.
> The relationship that you have with your boss ...
I should have been the guy who was always socializing with management at the office and happy hours. I should have been pushing my way into positions that were closer to the money itself - like getting contracts, attending conferences with management, architecture etc.
This is becoming even more apparent as I hit middle age, and it's harder to justify my high salary when the majority of our code isn't really all that complicated.
> and your bank account is what you need to focus on
But deep down I always knew this was true, so I lived frugally and saved most of my money. I honestly don't see a great future for guys like me who enjoy programming but are too introverted or just don't care to go into management positions. There is simply too many H1Bs, foreign competition, etc to justify high paid developers in most companies that aren't doing Google type development.
Bingo. I used to be that guy who'd spend my weekends fixing the code that everyone else left messed up on Friday or at the bookstore reading up on the latest framework. And I thought that someday it would be recognized with promotions or more pay or even a pat on the back.
Nope.
> The relationship that you have with your boss ...
I should have been the guy who was always socializing with management at the office and happy hours. I should have been pushing my way into positions that were closer to the money itself - like getting contracts, attending conferences with management, architecture etc.
This is becoming even more apparent as I hit middle age, and it's harder to justify my high salary when the majority of our code isn't really all that complicated.
> and your bank account is what you need to focus on
But deep down I always knew this was true, so I lived frugally and saved most of my money. I honestly don't see a great future for guys like me who enjoy programming but are too introverted or just don't care to go into management positions. There is simply too many H1Bs, foreign competition, etc to justify high paid developers in most companies that aren't doing Google type development.
This is something I've noticed early on even as a junior engineer (maybe it's my general upbringing that highlighted this well known fact of life). It becomes obvious quite quickly how little your knowledge and work matters. You can be incredibly smart and come up with wonderful solutions but it won't mean a thing if your boss(es) doesn't like you.
For a profession that has frequently professed meritocracy - it is certainly not. It's unfortunate.
For a profession that has frequently professed meritocracy - it is certainly not. It's unfortunate.
You need to focus on all, not to switch between one and the other.
It doesn't matter if your work is amazing if nobody realizes it (unless you are fine being a starving artist, no judgement)
The corollary isn't that you should make everyone think your inadequate work is amazing. I don't think you personally are making that judgement but there are people who would.
It doesn't matter if your work is amazing if nobody realizes it (unless you are fine being a starving artist, no judgement)
The corollary isn't that you should make everyone think your inadequate work is amazing. I don't think you personally are making that judgement but there are people who would.
What a great article.
Definitely goes under the heading of "Truths So True They Seem Obvious."
As for "Disorganized or messy code isn’t the same as technical debt," I can't look at messy code without automatically cleaning it up. It's automatic as I read and understand. In the last 5 years I've probably checked in hundreds of PR's of cleanup. If this takes anymore time and/or effort on my part I don't notice it. The only thing is someone has to merge it.
Definitely goes under the heading of "Truths So True They Seem Obvious."
As for "Disorganized or messy code isn’t the same as technical debt," I can't look at messy code without automatically cleaning it up. It's automatic as I read and understand. In the last 5 years I've probably checked in hundreds of PR's of cleanup. If this takes anymore time and/or effort on my part I don't notice it. The only thing is someone has to merge it.
I have a rule of thumb to assist with this. If i feel like I have to maintain some state in my mind to understand a particular piece of code then I opt to clean it up since it'll potentially save future developers that time.
The thing is, especially with juniors, cleaning up code leads to a few things:
- poorly executed cleanup (aka regressions)
- misunderstanding of requirements (new bugs)
- "standardization" of naming (now you have two standards https://xkcd.com/927/)
- restructuring of code/renaming of abstractions which then adds friction to original authors of code (provided they are still around)
Left unchecked this can all happen, at the expense of feature work, and an unmerged PR resulting in missed deadlines and a frustrated junior. Alas we usually learn best by making mistakes though and I find this one hard to teach for some juniors.
I would argue that a measured tolerance of ugly code (and sometimes bad code) is more important until you learn how to spot and write code that doesn't look wrong.
Two articles I found helpful:
https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- poorly executed cleanup (aka regressions)
- misunderstanding of requirements (new bugs)
- "standardization" of naming (now you have two standards https://xkcd.com/927/)
- restructuring of code/renaming of abstractions which then adds friction to original authors of code (provided they are still around)
Left unchecked this can all happen, at the expense of feature work, and an unmerged PR resulting in missed deadlines and a frustrated junior. Alas we usually learn best by making mistakes though and I find this one hard to teach for some juniors.
I would argue that a measured tolerance of ugly code (and sometimes bad code) is more important until you learn how to spot and write code that doesn't look wrong.
Two articles I found helpful:
https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
I read once someone's estimate that the probability of introducing a bug when fixing a bug is somewhere between 20 and 50 percent. That probably also applies if it's not a bug - if you're just cleaning up something. That should make you think twice.
In particular, it might make you think about game theory. Is the expectation value of this change more bugs, or less? Will making this change have at least a 50% chance of preventing a future bug?
In particular, it might make you think about game theory. Is the expectation value of this change more bugs, or less? Will making this change have at least a 50% chance of preventing a future bug?
There is the debt that is localized to a singular place, and there is the debt that is all over the place and that is a death by a thousand cuts. The former is easier to fix (and will probably be fixed by some enterprising person, but then second one is the more nefarious one that a lot fewer people actually take the time to do anything about.
As a Junior: Creating the most abstract grand architecture to apply to every facet of my application will solve all my problems.
As a Senior: Replacing all this architecture astronaut indirection with simple linear concrete code will solve all my problems.
As a Senior: Replacing all this architecture astronaut indirection with simple linear concrete code will solve all my problems.
Excellent article! Thank you, Monica. You just put into words a whole bunch of stuff that I always "sensed" but never "said".
After spending 7 million years (it sure seems like it) cleaning up the most vile garbage code you could possibly imagine, I'd like to elaborate on this:
Architecture is more important than nitpicking. While a small line of code could be improved, the stuff that tends to cause bigger problems down the line are usually architectural. I should’ve focused more on the structure of the application than tiny bits of code early on.
Architecture = the sum of all those seemingly unimportant "tiny bits of code".
It seems like every time I have to refactor or (heaven forbid) rewrite, I have to start deep down in those tiny bits. I've worked places with all these "genius" architects, but when I dive deep down into the code, I find a sewer than couldn't possibly support software life as we know it, no matter how brilliantly it was conceived.
Fellow programmers, you probably know exactly what I'm talking about, all those cancerous tiny bits that kill even the strongest patients:
Get good at the trees and the forest will flourish.
After spending 7 million years (it sure seems like it) cleaning up the most vile garbage code you could possibly imagine, I'd like to elaborate on this:
Architecture is more important than nitpicking. While a small line of code could be improved, the stuff that tends to cause bigger problems down the line are usually architectural. I should’ve focused more on the structure of the application than tiny bits of code early on.
Architecture = the sum of all those seemingly unimportant "tiny bits of code".
It seems like every time I have to refactor or (heaven forbid) rewrite, I have to start deep down in those tiny bits. I've worked places with all these "genius" architects, but when I dive deep down into the code, I find a sewer than couldn't possibly support software life as we know it, no matter how brilliantly it was conceived.
Fellow programmers, you probably know exactly what I'm talking about, all those cancerous tiny bits that kill even the strongest patients:
- variables so horribly named that no one could ever interpret them
- 800 line iterations surely destined to be broken by a maintenance programmer
- conditionals so illogical that no one can tell if they ever worked
- early exits to hell that can only be fixed by rewriting
- double negative logic that could not never fail to break
- 8 lines of code where 1 could do
- <add your own>
Get good at the trees and the forest will flourish.
From my experience of working at Fortune 100's for over 10 years as a senior engineer, I would say I have seen what you described, but rarely if ever are they the architects fault. There are usually just a few of them and usually hundreds of developers constantly shoveling garbage into the codebase. They rely upon processes and such... but they all fall apart in practice.
I've come to the conclusion good is good enough and working is even better. Usually the business agrees.
I've come to the conclusion good is good enough and working is even better. Usually the business agrees.
> - early exits to hell that can only be fixed by rewriting
What do you mean by that?
if (a) {
do_something();
return;
} else if (b) {
do_something();
if (something_else() == -1) {
return;
}
}
do_other_things();
maybe_exit_here();
maybe_keep_going();
I'd argue that this sort of thing is fine, as long as the `return` is not nested deeply. A function which starts with a list of 'early exit' simple conditions is fairly easy to deal with, compared with one where you need to read the whole thing to check that the value assigned to the returned variable isn't reassigned later in a different condition. Early returns can significantly reduce cognitive load if used correctly precisely because they exit directly.
Once you have complex bail-out scenarios, the function needs breaking up or insanity follows... but that's true of any sufficiently confusing decision tree.
Generally I have found `else` to be something of an antipattern. I usually find it cleaner to write the code as 'this special early bail-out with a return, and the other case is just the rest of the function'. A bit like pattern-matching in Haskell, or a `switch` block in which the default case is the usual one. I also try to avoid reassigning variables, eg. in Typescript everything would be `const`.
But like all generalities, these have exceptions!
Once you have complex bail-out scenarios, the function needs breaking up or insanity follows... but that's true of any sufficiently confusing decision tree.
Generally I have found `else` to be something of an antipattern. I usually find it cleaner to write the code as 'this special early bail-out with a return, and the other case is just the rest of the function'. A bit like pattern-matching in Haskell, or a `switch` block in which the default case is the usual one. I also try to avoid reassigning variables, eg. in Typescript everything would be `const`.
But like all generalities, these have exceptions!
GOTO return(); is the droid you're looking for. :)
Multiple of these points could be grouped under the general belief that "Everything is equally important". The #1 change required for growing into a senior role is to form a habit of ruthless prioritization of how you spend your time (and your team's time, if applicable).
Often you end up in situations where all of the following are true:
1. Your teammate or colleague is designing or implementing something.
2. You have different ideas about how that thing should be done.
3. Your ideas would produce an objectively better system.
4. Even though (3) is true, the improvement to the system or design isn't worth the cost in your time, team velocity, team morale/development, etc.
In that case, the right move is not to intervene, and to let your teammate design/implement the system their way. This is hard to do, because most engineers are natural maximizers[1], but for most tasks you're much better off with a satisficing[2] approach. This isn't to say that you should never give feedback on designs or in code reviews - you absolutely should, but always remember that you have a limited budget for your own time and for team morale, and you should spend that budget on the feedback where it will make the biggest difference.
[1] https://en.wikipedia.org/wiki/Maximization_(psychology)
[2] https://en.wikipedia.org/wiki/Satisficing
Often you end up in situations where all of the following are true:
1. Your teammate or colleague is designing or implementing something.
2. You have different ideas about how that thing should be done.
3. Your ideas would produce an objectively better system.
4. Even though (3) is true, the improvement to the system or design isn't worth the cost in your time, team velocity, team morale/development, etc.
In that case, the right move is not to intervene, and to let your teammate design/implement the system their way. This is hard to do, because most engineers are natural maximizers[1], but for most tasks you're much better off with a satisficing[2] approach. This isn't to say that you should never give feedback on designs or in code reviews - you absolutely should, but always remember that you have a limited budget for your own time and for team morale, and you should spend that budget on the feedback where it will make the biggest difference.
[1] https://en.wikipedia.org/wiki/Maximization_(psychology)
[2] https://en.wikipedia.org/wiki/Satisficing
This really hits home to me. I worked on a project where I encountered an almost identical situation to the one you described. I stuck my foot down, and insisted we build the objectively better solution. We did, and only much later did I realise the damage I had done to my coworker's morale.
Looking back, I completely regret it. If I had my time again, I would stop after explaining the alternate solution. The time we would have had to spend fixing the problems with the original approach would have been worth it.
I've heard this repeated a lot, but I'm really only just starting to understand: Often the best leaders speak up less, rather than more.
Looking back, I completely regret it. If I had my time again, I would stop after explaining the alternate solution. The time we would have had to spend fixing the problems with the original approach would have been worth it.
I've heard this repeated a lot, but I'm really only just starting to understand: Often the best leaders speak up less, rather than more.
> I also learned that job titles don’t “make” you anything. It’s kind of like, being a CTO with a 5-person team is different than with a 50-person team or a 500-person team. The job and skills required are totally different, even if the title is identical. So just because I had a “senior” job title did not make me a senior engineer at all. Furthermore, hierarchical titles are inherently flawed, and difficult to compare cross-company. I learned it’s important not to fixate on titles, or use them as a form of external validation.
Unfortunately, they do matter in the real world.
Unfortunately, they do matter in the real world.
They certainly "matter" but I think the point more is that skills, responsibilities, ability from one place to the next with the same title is not a good comparison.
True, but the realisation above is key to understanding how career progression works once you hit your cap. A developer can become a senior developer and then a technical lead and then... what? A manager? You can't really go past technical lead while still staying in the trenches.
So what you need to do is be the tech lead for a team working on a bigger problem. Your job title doesn't have to change as long as you're working on a bigger job.
So what you need to do is be the tech lead for a team working on a bigger problem. Your job title doesn't have to change as long as you're working on a bigger job.
Well, depends. I know people going from CTO of a small start-up to individual contributor in a bigger company, probably for money.
Titles count a lot inside an organisation, thought.
Titles count a lot inside an organisation, thought.
I used to work with one of those, he traded his title and pay for a work permit in another country
> "Good enough is good enough"
+1000 to this. Please don't be the guy that slows me down and prevents me from delivering features because you insist on everything being perfect. I can't tell you how many times and how much money people who are obsessed with code quality waste. They spend months polishing code only to get out a feature that no one uses and doesn't matter. But hey, the code is "perfect"!
+1000 to this. Please don't be the guy that slows me down and prevents me from delivering features because you insist on everything being perfect. I can't tell you how many times and how much money people who are obsessed with code quality waste. They spend months polishing code only to get out a feature that no one uses and doesn't matter. But hey, the code is "perfect"!
Who defines what "good enough" means? Is it basic functionality? What if that basic functionality contains security vulnerabilities? What if it is written in such a way that will cause potential, foreseeable problems down the road? What if it is written in such a way that it is only understandable to the author? What exactly is "good enough?"
I’ve found it’s far better to error on the side of speed and work pragmatically on features rather than trying to deliver perfection. That’s just me though. Nothing is going to be free of defect or perfectly secure.
> Documentation lies
This is a very true statement, especially concerning legacy codebases. I have worked on some projects that have had several developers make changes to it.
The original developers were great: they commented every class, had comments for all the methods, and added comments for any complex or funky logic.
Then the changes came. And the next developers hacked and slashed the existing code base to meet the new spec. Except they did not update any of the comments, so now what was once true and reliable is now frail and questionable.
Now, whenever I inherit legacy code riddled with comments, the first thing I do is delete all the comments. This helps me focus on what the code is actually doing, rather than what someone thrice-removed said it should be doing.
This is a very true statement, especially concerning legacy codebases. I have worked on some projects that have had several developers make changes to it.
The original developers were great: they commented every class, had comments for all the methods, and added comments for any complex or funky logic.
Then the changes came. And the next developers hacked and slashed the existing code base to meet the new spec. Except they did not update any of the comments, so now what was once true and reliable is now frail and questionable.
Now, whenever I inherit legacy code riddled with comments, the first thing I do is delete all the comments. This helps me focus on what the code is actually doing, rather than what someone thrice-removed said it should be doing.
I was thinking about this and because of the book _Clean Code_ I had already decided that comments will lie at some point.
So I moved towards descriptive variable and function names, but those could lie as well.
So I'm thinking, how could we ensure truthful intentions at all?
And I think only a combination of small pull requests, good variable and function names and a thorough review can save us here.
But I don't know, I'm just a junior developer.
So I moved towards descriptive variable and function names, but those could lie as well.
So I'm thinking, how could we ensure truthful intentions at all?
And I think only a combination of small pull requests, good variable and function names and a thorough review can save us here.
But I don't know, I'm just a junior developer.
Types can help. Your code simply won't compile if the types are wrong.
The catch is that you have to define way more types, but if the code is complex enough it's really worth it.
The catch is that you have to define way more types, but if the code is complex enough it's really worth it.
Personally, I think the best thing is education. Now more than ever (in this agile / scrum world) devs are making small, quick changes to existing codebases. These small changes add up, and what was once a great, clean codebase is now riddled with hacks and mis-documented code.
I think educating the developer / team on the existing codebase first would be the right step. Spend a day just going through the code. Learn how it connects, learn the full scope of the project. After this, make your changes in a way that fit into the existing code.
I've had too many offshore developers re-imnplement existing functionality, like reading data from an excel spreadsheet, simply because they did not look through the code that was already there. It cost them 2 hours of work to add another library and implement it, when the code they already needed was a simple using statement away.
In theory, this is why good orgs have senior devs: they know the codebases already. Furthermore, they should be reviewing these changesets to call out devs who mis-document or scatter about the code. But senior devs are people too, and they miss things. Additionally, some codebases are enormously complex, and it's virtually impossible for a single dev to understand it completely.
I think educating the developer / team on the existing codebase first would be the right step. Spend a day just going through the code. Learn how it connects, learn the full scope of the project. After this, make your changes in a way that fit into the existing code.
I've had too many offshore developers re-imnplement existing functionality, like reading data from an excel spreadsheet, simply because they did not look through the code that was already there. It cost them 2 hours of work to add another library and implement it, when the code they already needed was a simple using statement away.
In theory, this is why good orgs have senior devs: they know the codebases already. Furthermore, they should be reviewing these changesets to call out devs who mis-document or scatter about the code. But senior devs are people too, and they miss things. Additionally, some codebases are enormously complex, and it's virtually impossible for a single dev to understand it completely.
Variable names can also go stale - you should consider replacing all the variable names with placeholders. /s
Deleting all the comments is too far in the extreme. How about just read them and realize they could be stale?
Deleting all the comments is too far in the extreme. How about just read them and realize they could be stale?
I've been programming professionally for well over 20 years (and many years prior as a hobby), and held "senior" to "C-level" positions. in my eyes I'm still a junior kid learning new stuff all the time. When I stop seeing myself as that, I'll switch vocation.
"Loads of companies and startups have little or no tests" which should scare you, or at least it would scare me if I joined a team.
You can definitely over test, but how can you possibly know what you built works (or still works when you change it for the 50th time) if you have no tests? There's a trade-off with testing. Early in the dev cycle, not testing can make you go super fast (supposedly, this hasn't been my personal experience but in general it seems to be true for teams). But you'll plateau quickly and then at iteration 1+n you'll just come to a screeching halt because you introduce bugs or the new engineer isn't confident that they didn't break downstream things and needs to manually test everything. Testing early will cause you to go slower earlier (again, not my personal experience but seems to be generally true of teams) but you'll be significantly faster at iteration 1+n.
I usually summarize this as: testing early will on average make your development faster over the life of your codebase. Knowing this you can make trade-offs. Not testing early is probably better called prototyping. It's OK to prototype in production if you need to. But know what you're getting yourself into.
You can definitely over test, but how can you possibly know what you built works (or still works when you change it for the 50th time) if you have no tests? There's a trade-off with testing. Early in the dev cycle, not testing can make you go super fast (supposedly, this hasn't been my personal experience but in general it seems to be true for teams). But you'll plateau quickly and then at iteration 1+n you'll just come to a screeching halt because you introduce bugs or the new engineer isn't confident that they didn't break downstream things and needs to manually test everything. Testing early will cause you to go slower earlier (again, not my personal experience but seems to be generally true of teams) but you'll be significantly faster at iteration 1+n.
I usually summarize this as: testing early will on average make your development faster over the life of your codebase. Knowing this you can make trade-offs. Not testing early is probably better called prototyping. It's OK to prototype in production if you need to. But know what you're getting yourself into.
Tests are anti-agile. TDD is waterfall. Legacy tests add friction to making changes. Sometimes you want that friction but in a frenetic prototyping phase its detrimental. This is especially true when business goals are changing constantly (such as early prototyping).
How do you know what you built works? The only thing that truly matters is that the user story is satisfied and to that end unit tests are terrible. At best you could make some integration tests but that is not the same thing.
I also think there are better practices than tests to keep iteration pain low but that doesn't preclude tests so I guess that's not an argument against them. That said I prefer to focus on making composable, low side effect code than write more tests.
Personally I hate tests although I come from games where you need human QA testers to test that your game feels fun anyway so I do admit that's a unique situation.
How do you know what you built works? The only thing that truly matters is that the user story is satisfied and to that end unit tests are terrible. At best you could make some integration tests but that is not the same thing.
I also think there are better practices than tests to keep iteration pain low but that doesn't preclude tests so I guess that's not an argument against them. That said I prefer to focus on making composable, low side effect code than write more tests.
Personally I hate tests although I come from games where you need human QA testers to test that your game feels fun anyway so I do admit that's a unique situation.
> Tests are anti-agile. TDD is waterfall. Legacy tests add friction to making changes.
Strongly disagree. Tests empower agile.
Here's a module/class/object/file. The unit tests test the externally visible behaviors of that code. Now stuff happens; the code needs to change. That's OK, we're agile, we can deal with it. I make the changes.
What did I break? I run the existing tests. Some break. Is that because the test doesn't reflect the new changes? I fix those tests. Or is it because I broke something? Good to know that early. I fix my code.
Next question: Did my changes do what they needed to do? For that, I write new tests.
Finding your problems early is a big part of agile. Tests are a big part of finding your problems early.
Now: If you're prototyping a new algorithm, would I write detailed unit tests before it gels? Probably not. (In XP, we called this a "spike" - trying to nail something down, not necessarily writing production code.) But even then, how do you know that your algorithm does what you need it to do? Maybe some tests?
Strongly disagree. Tests empower agile.
Here's a module/class/object/file. The unit tests test the externally visible behaviors of that code. Now stuff happens; the code needs to change. That's OK, we're agile, we can deal with it. I make the changes.
What did I break? I run the existing tests. Some break. Is that because the test doesn't reflect the new changes? I fix those tests. Or is it because I broke something? Good to know that early. I fix my code.
Next question: Did my changes do what they needed to do? For that, I write new tests.
Finding your problems early is a big part of agile. Tests are a big part of finding your problems early.
Now: If you're prototyping a new algorithm, would I write detailed unit tests before it gels? Probably not. (In XP, we called this a "spike" - trying to nail something down, not necessarily writing production code.) But even then, how do you know that your algorithm does what you need it to do? Maybe some tests?
Tests might make you personally feel safer making changes but they are not Agile(tm) because they attempt to predict needs instead solving an explicit existing need. They violate YAGNI and worse there is work in removing and rewriting old tests.
I see absolutely nothing in the Agile Manifesto that precludes tests. Nor do I see any basis for saying that tests attempt to predict needs. They are for the future, true, but they're also for the present - as is every line of code you write.
>Nor do I see any basis for saying that tests attempt to predict needs
The prediction is that the next time you revisit this code your original assumptions will still be valid. In games, which is my background, game rules (our business logic) are constantly changing during development to the point that you're fighting tests constantly for no benefit. Games are an extreme case but you can extrapolate the experience.
You've already admitted that there is a point when tests are not worthwhile when you are iterating. My argument is simply that in my experience you're in that state more often than not. Ultimately user value is the only thing that matters and tests don't predict that.
And I'm not saying you're not allowed to write tests. If something helps you do it. I'm arguing against code coverage and test enforcement.
The prediction is that the next time you revisit this code your original assumptions will still be valid. In games, which is my background, game rules (our business logic) are constantly changing during development to the point that you're fighting tests constantly for no benefit. Games are an extreme case but you can extrapolate the experience.
You've already admitted that there is a point when tests are not worthwhile when you are iterating. My argument is simply that in my experience you're in that state more often than not. Ultimately user value is the only thing that matters and tests don't predict that.
And I'm not saying you're not allowed to write tests. If something helps you do it. I'm arguing against code coverage and test enforcement.
> The prediction is that the next time you revisit this code your original assumptions will still be valid.
No. The tests will encode the previous assumptions. When you run them, and they fail, either you broke something or one of the previous assumptions is no longer valid. But the tests give you an automated way of recognizing which assumptions you'd better think about, to see if they are still valid.
> Games are an extreme case but you can extrapolate the experience.
No - no more than you can extrapolate my experience, which is having core logic that is (mostly) valid a decade later.
> I'm arguing against code coverage and test enforcement.
Or at least against those things in areas that are constantly changing. Even in your world, though, are there areas that change more slowly than the game rules? Would it make sense to have tests for those areas, and not for the game rules?
No. The tests will encode the previous assumptions. When you run them, and they fail, either you broke something or one of the previous assumptions is no longer valid. But the tests give you an automated way of recognizing which assumptions you'd better think about, to see if they are still valid.
> Games are an extreme case but you can extrapolate the experience.
No - no more than you can extrapolate my experience, which is having core logic that is (mostly) valid a decade later.
> I'm arguing against code coverage and test enforcement.
Or at least against those things in areas that are constantly changing. Even in your world, though, are there areas that change more slowly than the game rules? Would it make sense to have tests for those areas, and not for the game rules?
I still struggle to understand the real benefit of unit tests; the most intuitive tests that test real business logic that I've written always become something like semi-integration tests. Pure unit tests that test a small isolated function are almost never useful to catch bugs after they're written. The only legitimate use for them has been that it's easier to understand the purpose of the function and edge cases. At times it makes me think about edge cases and identify bugs WHIlE writing the tests, but once they're written, they're never useful unless someones actively trying to understand that exact unit of code.
For unit testing, I suggest starting with parsers, or any string-parsing code you have. They tend to be nicely self-contained and have lots of edge cases that you can test in a data-driven way, using a loop.
Even if you're just using a regular expression for parsing, it can be worth moving the parsing code to its own function and testing it like a parser.
Even if you're just using a regular expression for parsing, it can be worth moving the parsing code to its own function and testing it like a parser.
Depends on how you define a unit and what you're willing to mock.
I treat a 'unit' as a piece of functionality. So one method on an API is a unit. if it does complex stuff then there may be more targeted tests down below. and depending on what sort of work it does i may not bother with unit tests because mocking a DB transaction isn't worth it.
In java land when I'm writing stuff i use unit tests mostly as a place where i can run code without having to compile the whole app. And any tests that come out of it just end up being a bit of regression protection. But there's always a bigger slightly more complex unit test i write which tests the bigger unit of function. And those really straddle the line between unit and integration testing but i find i get the most value from them because one you lock in and publish functionality you have a contract you have to honor.
In java land when I'm writing stuff i use unit tests mostly as a place where i can run code without having to compile the whole app. And any tests that come out of it just end up being a bit of regression protection. But there's always a bigger slightly more complex unit test i write which tests the bigger unit of function. And those really straddle the line between unit and integration testing but i find i get the most value from them because one you lock in and publish functionality you have a contract you have to honor.
You say you've never understood the benefit of unit tests but you list three really great things: they help you debug stuff while you're writing it, they help you understand what you're writing and the edge cases, and they help others understand your code later. That's all great stuff.
The benefit is being able to make changes and sleep soundly at night.
I agree with the grandparent that they are more useful as a project matures rather than the design stage. Starting small and adding tests as designs solidify is a good tradeoff.
I agree with the grandparent that they are more useful as a project matures rather than the design stage. Starting small and adding tests as designs solidify is a good tradeoff.
you have a lot to unlearn, young padawan. you must first forget what you know ...
You are making the assumption that most people care about n+1 where the code gets so bad it’s hard to maintain.
- the average tenure for a software developer at a company is 1.5 - 3 years, by the time things get that bad, its someone else’s problem.
- the business folks at a startup just care about throwing something together long enough to get their next round of funding or the exit.
- no one gets promoted by having code that is easy to maintain over the long term. They get promoted by releasing the new and shiny - not maintenance work. See Google.
- the average tenure for a software developer at a company is 1.5 - 3 years, by the time things get that bad, its someone else’s problem.
- the business folks at a startup just care about throwing something together long enough to get their next round of funding or the exit.
- no one gets promoted by having code that is easy to maintain over the long term. They get promoted by releasing the new and shiny - not maintenance work. See Google.
> how can you possibly know what you built works (or still works when you change it for the 50th time) if you have no tests?
Because software development did exist before the invention of JUnit et al. The old fashioned way is 'user acceptance tests' and of course thats not perfect but its easily understandable, and nearly anyone can sit there and do it. And they might miss things or whatever yadda yadda but at the end of the day in an environment where everyone is short of time and time is money a bit of user testing can often be 'good enough'.
Because software development did exist before the invention of JUnit et al. The old fashioned way is 'user acceptance tests' and of course thats not perfect but its easily understandable, and nearly anyone can sit there and do it. And they might miss things or whatever yadda yadda but at the end of the day in an environment where everyone is short of time and time is money a bit of user testing can often be 'good enough'.
I’m not saying you need 100% code coverage, or 80%. Just some level of deliberate automation. In my personal experience, user testing as your only or primary form of testing gets painful fast.
Having lived through the screeching halt, I agree. There reaches a point where you genuinely cannot make a change without breaking something on the live system, or taking five times as long as is reasonable. You no longer have any idea what the real behaviour of the system or why (doco is NEVER up to date). Not having tests was part of the reason I changed jobs.
I don’t know why people assume that tests hold you back from changes. If they do, they were just bad tests which were testing implementation details rather than businsss logic. That’s an argument to not write useless/stupid tests, not an argument to not write any tests at all. It just seems to be far more difficult for developers to decide what a good test should look like than to decide what any other good code should look like.
I don’t know why people assume that tests hold you back from changes. If they do, they were just bad tests which were testing implementation details rather than businsss logic. That’s an argument to not write useless/stupid tests, not an argument to not write any tests at all. It just seems to be far more difficult for developers to decide what a good test should look like than to decide what any other good code should look like.
A workflow using the code is a itself a type of test. If something breaks, the users will tell you. A lot of code ends up in that space because it was never asked for as an actual project, but now a team relies on it but no developer can be officially assigned to it.
"I don't always test my code, but when I do, I do it in production."
There are some programs that are not designed to last. It doesn't make sense to put in time in that regard.
About two years ago, I didn't get a promotion to "senior engineer" that I thought I was going to, and I had a huge temper-tantrum to my boss about it as a result (I'm still surprised to this day that I didn't quit on the spot, to be honest).
I was upset, because people that seemed to be contributing less and were less-qualified (at least from my admittedly-biased perspective at the time) were promoted to a higher level than me, and I got a fairly form-letter-esque answer of "we don't have the budget to promote you this time".
The next cycle, they corrected it, and I was officially a "senior engineer" on paper, and I realized how silly my hissy-fit had been. Sure, I guess having a bit more money was nice, but it's not like it radically changed the quality of my life, it's not like having a fancy title changed how people really saw me, and I didn't even bother updating the title on LinkedIn.
I don't think I was "wrong" in what I said. I do think that I deserved the promotion over someone else, but at the same time, I also tarnished a relationship with my boss and coworkers, and I let it get me far more depressed than it should have.
-------
I guess if any "junior" engineers are reading this, try and remember that a title is simply that: a title. They don't matter a lot, try to not get too upset over them, and obsessing over something so nominal is a great way to build up anxiety.
EDIT: Just a note, I absolutely think you should call out a company if you feel like you're being taken for granted. I'm not advocating complacency, just make sure that your hatred is directed to the right places and try to avoid getting too depressed.
I was upset, because people that seemed to be contributing less and were less-qualified (at least from my admittedly-biased perspective at the time) were promoted to a higher level than me, and I got a fairly form-letter-esque answer of "we don't have the budget to promote you this time".
The next cycle, they corrected it, and I was officially a "senior engineer" on paper, and I realized how silly my hissy-fit had been. Sure, I guess having a bit more money was nice, but it's not like it radically changed the quality of my life, it's not like having a fancy title changed how people really saw me, and I didn't even bother updating the title on LinkedIn.
I don't think I was "wrong" in what I said. I do think that I deserved the promotion over someone else, but at the same time, I also tarnished a relationship with my boss and coworkers, and I let it get me far more depressed than it should have.
-------
I guess if any "junior" engineers are reading this, try and remember that a title is simply that: a title. They don't matter a lot, try to not get too upset over them, and obsessing over something so nominal is a great way to build up anxiety.
EDIT: Just a note, I absolutely think you should call out a company if you feel like you're being taken for granted. I'm not advocating complacency, just make sure that your hatred is directed to the right places and try to avoid getting too depressed.
Nah, f that mess. If you find yourself in a place that promotes the weak because it's a buddy system, it's not a place to work long-term. It means your boss is in 'don't rock the boat mode' and that's going to hold you back long term. Your boss should be fighting for promotions for their best workers and enabling growth in responsibility as well.
Oh, in fairness to my boss, he did make a strong effort in the next promotion cycle to get me promoted, which in fairness was only 6 months later.
The issue was the they had a limited budget for promotions, and basically limited it to one person per team. This, by itself wouldn't have bothered me too much, since the person who deserved it most on my team (someone with more experience than me, and was definitely under-leveled) did get promoted that cycle.
What upset me most was that a person on another team (with 1/3 of my experience, with no increased education, and on a team that accomplished nothing (not just my opinion, that team was disbanded a year later)) got promoted to a level higher than me. My direct boss didn't have any control on that team.
The issue was the they had a limited budget for promotions, and basically limited it to one person per team. This, by itself wouldn't have bothered me too much, since the person who deserved it most on my team (someone with more experience than me, and was definitely under-leveled) did get promoted that cycle.
What upset me most was that a person on another team (with 1/3 of my experience, with no increased education, and on a team that accomplished nothing (not just my opinion, that team was disbanded a year later)) got promoted to a level higher than me. My direct boss didn't have any control on that team.
Yeah, that clears things up. I think every organization has those dead-weight teams. As long as you put tons of points on your stories in Jira, you look super busy and management gets to see your pretty charts.
Remember: once you retire, no one cares if you were a director. When you are 60, you are just old. The people that do care, you probably don't want to be friends with them.
I'm currently wanting "senior" in my title because of a recurring issue with interviewing for new positions. I often get stuck at talking to HR because from my years of experience they assume I'm MUCH less expensive than I am. I could use the title so that I could stop running into this as much.
I've always found the obsession with titles somewhat strange in our business. In my 7-8 jobs since college, I've never really had a 'formal' title. It just seems like all 'developers' are thrown into the same bin, and the better ones are team leads who don't have any actual authority to do anything (e.g. order a new laptop or approve of a hire).
After about 10 years, I just started calling myself a 'senior software engineer' on my resume and nobody has ever called me out on it.
Must be a Silicon Valley thing tied to salary. But in the areas I've worked, titles don't seem to exist for non-management.
After about 10 years, I just started calling myself a 'senior software engineer' on my resume and nobody has ever called me out on it.
Must be a Silicon Valley thing tied to salary. But in the areas I've worked, titles don't seem to exist for non-management.
I think it's the same compulsion that makes many (though not all) people who get a PhD feel like they have to mention that fact everywhere (e.g. Dr. John Doe, Ph.D.).
My title is senior application engineer. I don't think I've ever actually said that out loud. I just tell people I'm a developer. Titles are meaningless beyond letting HR know what salary band I should be in.
Yeah, same here. I was excited to get the promotion, but when people ask what I do for a living, I typically say "eccentric" for a more casual conversation, and "software engineer" for something more serious. I realize now that if you have to rely on titles for people to take you seriously, you probably aren't making great points.
I recently changed job, and went from being a "principal engineer" to being an "engineer" (in a company that doesn't do titles). There's more to life.
Senior is as senior does.
The #1 absolute truth I unlearned was: The solution to your problem is the tech stack or framework you're not using. Everyone in this industry seems to have tech wanderlust; using the latest and greatest and unproven is seen as sexy.
* "Oh we could do that, but we're on python 2.7"
* "Oh we could do that, but we're using Java"
* "Oh we could do that, but we're using a relational database"
* "Oh we could do that, but we're on python 2.7"
* "Oh we could do that, but we're using Java"
* "Oh we could do that, but we're using a relational database"
1. Code and communication are the most important. If you are writing extremely bad code, you will be annoyed how much time you will need to go though to find the bug. The more you do, the more you will not like to touch the code even they are written by you. (I have seen someone with this experience) Understanding what your teammates are doing is also important in order to support each other and provide valued advices, in this case code is a communication medium.
2. To write good software, we cannot just be a coder, we need to understand the business and the project management
3. There are many seniors became senior because of their age not their ability. I am not talking about using a particular tech, I am talking about their mind. Many of them still think like junior even they are at a senior position, the way they are working didn’t scale at all.
4. Fundamentals is very important. https://hackernoon.com/the-doctor-and-the-scalpel-78656f508c...
2. To write good software, we cannot just be a coder, we need to understand the business and the project management
3. There are many seniors became senior because of their age not their ability. I am not talking about using a particular tech, I am talking about their mind. Many of them still think like junior even they are at a senior position, the way they are working didn’t scale at all.
4. Fundamentals is very important. https://hackernoon.com/the-doctor-and-the-scalpel-78656f508c...
Great post. Lot's of good stuff.
Just to comment on one part at random:
Code reviews would be more useful if review feedback was categorized:
1. is this a matter of personal style? 2. is this a judgement call? 3. is this something that is just wrong and has to be fixed? 4. is this in-scope or actually a separate issue?
(This is off the top of my head, so this is more of an example of the kind of categorization I'm talking about than a proposal.)
It's useful because it helps to set the direction and expectations on what to do about an item of feedback.
E.g. if you have a lot of 1. then the right "fix" might be to spin off a task to develop a common style-guide. (Or maybe fix an out-of-date a style guide, or to enforce an existing style-guide so that these issues don't dominate code reviews, etc.). For 4. the resolution would be to open a ticket (or whatever the process is so it gets proper consideration, prioritization, etc.)
Where I am currently we spend a lot of effort figuring out what to do about review feedback (and I think we too often make non-optimal decisions which sucks time as well).
Just to comment on one part at random:
Code reviews would be more useful if review feedback was categorized:
1. is this a matter of personal style? 2. is this a judgement call? 3. is this something that is just wrong and has to be fixed? 4. is this in-scope or actually a separate issue?
(This is off the top of my head, so this is more of an example of the kind of categorization I'm talking about than a proposal.)
It's useful because it helps to set the direction and expectations on what to do about an item of feedback.
E.g. if you have a lot of 1. then the right "fix" might be to spin off a task to develop a common style-guide. (Or maybe fix an out-of-date a style guide, or to enforce an existing style-guide so that these issues don't dominate code reviews, etc.). For 4. the resolution would be to open a ticket (or whatever the process is so it gets proper consideration, prioritization, etc.)
Where I am currently we spend a lot of effort figuring out what to do about review feedback (and I think we too often make non-optimal decisions which sucks time as well).
The last couple of teams I've been on have had the custom of prefixing any issue that is purely stylistic in nature with 'nit:'.
I think another truth to unlearn is "users know what they want, and can express what they want in precise technical terms."
And the complementary truth would be "I know what the user wants".
My team and I are kind of trying to break this up, since we suffer from this a lot.
My team and I are kind of trying to break this up, since we suffer from this a lot.
I don't know if I can call myself a senior. (none of the companies I've worked for have used senior/junior in their job titles), but one of the most important pieces of information I've picked up is this:
The Simplest way is usually the right way.
What I mean is that fancy algorithms, sweeping design patterns, and "clever" pieces of code are generally not the best approach to 99% of coding specific problems.
Example: Nested for-loops. Generally a bad choice. When encountering a nested for-loop, one may be tempted to try and refactor it into some sort of recursive and highly-performant function with O(n) complexity, etc. You go through all that work and then realize that the most iterations that for loop will ever see is ~10. You just wasted a ton of time writing code that is more complex, harder to debug, and generally more opaque.
In my experience, I've seen this a lot in the context of premature optimization. I've also been the perpetrator many times as well.
The Simplest way is usually the right way.
What I mean is that fancy algorithms, sweeping design patterns, and "clever" pieces of code are generally not the best approach to 99% of coding specific problems.
Example: Nested for-loops. Generally a bad choice. When encountering a nested for-loop, one may be tempted to try and refactor it into some sort of recursive and highly-performant function with O(n) complexity, etc. You go through all that work and then realize that the most iterations that for loop will ever see is ~10. You just wasted a ton of time writing code that is more complex, harder to debug, and generally more opaque.
In my experience, I've seen this a lot in the context of premature optimization. I've also been the perpetrator many times as well.
Premature optimization comes in many forms, and at least these three cases are doing more harm than good:
1: "It's good practice"
For example: Wrapping every function implementation in a memoize function may seem like a good idea (= it prevents doing unnecessary work-heavy stuff), but it actually makes code both harder to read (more boilerplate to skip when reading) and most cases slower (= even when a function is executed only once, you're doing extra checks and function call).
2. "We're gonna need this soon"
For example: many times I've implemented an abstraction that makes sense for sharing code with a feature that I know we'll be implementing soon, only to find out priorities have changed and that other feature never gets implemented. What's left is an unnecessary abstraction that only makes the code harder to read and maintain.
3: Optimising for speed/lines of code
Unless you're building a game engine, it rarely makes bang for the buck to optimise for speed until you have identified an actual bottleneck in performance.
Same for one-liners. It may be cool that you know how to write 10-line function as one-liner nested ternary, but your "clever" code is probably less readable and harder to maintain.
1: "It's good practice"
For example: Wrapping every function implementation in a memoize function may seem like a good idea (= it prevents doing unnecessary work-heavy stuff), but it actually makes code both harder to read (more boilerplate to skip when reading) and most cases slower (= even when a function is executed only once, you're doing extra checks and function call).
2. "We're gonna need this soon"
For example: many times I've implemented an abstraction that makes sense for sharing code with a feature that I know we'll be implementing soon, only to find out priorities have changed and that other feature never gets implemented. What's left is an unnecessary abstraction that only makes the code harder to read and maintain.
3: Optimising for speed/lines of code
Unless you're building a game engine, it rarely makes bang for the buck to optimise for speed until you have identified an actual bottleneck in performance.
Same for one-liners. It may be cool that you know how to write 10-line function as one-liner nested ternary, but your "clever" code is probably less readable and harder to maintain.
Properly choosing an algorithm or data structure is first knowing the nature of your data.
Sidenote: I believe in general a Senior developer is 8-10 years with a general expectation that you will mentor junior developers.
YMMV depending upon region and company.
YMMV depending upon region and company.
One thing I learned as a developer for 12+ years is that the title is meaningless and where I work, many of the highest impact developers would be considered 'junior' developers. I wonder why people have such an infatuation with the title 'junior' and 'senior'. Seems to be more prevalent in European countries.
One thing the OP mentioned but I think isn't talked about much is that for me everyone has their own style. Some people have great abstractions, others lots of tests, some more code comments, interesting variable name choices, some like functional-style, or lots of frameworks & patterns etc. From our team I can often see who wrote something just from how its written.
Now as a junior I just wrote how I liked and hated everyone else's code. Then came a long awkward phase where I tried to fit in closely with other people's styles and figure out their intent and design - this is a very difficult way to write code and I wasn't very productive. I thought about this a lot and now I just go ahead and blaze a trail and other people can just figure out my style. Move fast and break things - or being reckless, its often hard to tell, but you wont be a 10x dev by trying to be nice and fit it.
Now as a junior I just wrote how I liked and hated everyone else's code. Then came a long awkward phase where I tried to fit in closely with other people's styles and figure out their intent and design - this is a very difficult way to write code and I wasn't very productive. I thought about this a lot and now I just go ahead and blaze a trail and other people can just figure out my style. Move fast and break things - or being reckless, its often hard to tell, but you wont be a 10x dev by trying to be nice and fit it.
Interestingly, I'm at that unproductive phase right now. On one hand, I could fix this fast and ugly, but then my code is going to look no different then all the code I go home and complain about. On the other hand, I can try to make my code really nice and abstracted with well thought out design patterns like <golden-coworker>'s. So, on one hand I'm a hypocrite and on the other hand I'm slow and hardly productive because I am just learning design patterns and no matter how many times I refactor my code it never looks as good as <golden-coworkers>'s. How did you get out of this stage? Please help.
This is surely debatable, but the best code is readable by Engineers of Tomorrow with the least amount of effort.
Getting code reviews from other people that understand this, or pair programming with them, is the best way to practice empathy for those future code readers (which very well may be you).
Don't focus on commenting about how. They can read the code for that, and those comments almost always drift from truth. Instead, focus on writing code and comments that describe the why. Consider describing what other approaches you tried, why you didn't use them, and why you went with the current implementation.
This especially applies if your solution may not be the obvious first answer.
Try to help the Engineers of Tomorrow from repeating prior mistakes. Free them up to make new and grander mistakes, instead.
Getting code reviews from other people that understand this, or pair programming with them, is the best way to practice empathy for those future code readers (which very well may be you).
Don't focus on commenting about how. They can read the code for that, and those comments almost always drift from truth. Instead, focus on writing code and comments that describe the why. Consider describing what other approaches you tried, why you didn't use them, and why you went with the current implementation.
This especially applies if your solution may not be the obvious first answer.
Try to help the Engineers of Tomorrow from repeating prior mistakes. Free them up to make new and grander mistakes, instead.
I think that is nice, but may not be aligned with what the company wants. If <golden coworker> is respected, well paid and promoted then by all means try to emulate them. if <golden coworker> is gold plating a lot of small projects that dont really help the business, and hackers are getting rewarded for delivering new functionality that the bosses want, then that route is better.
> Then came a long awkward phase where I tried to fit in closely with other people's styles and figure out their intent and design - this is a very difficult way to write code and I wasn't very productive.
My first gig was at a 3 person team, including me. The other two wrote their code in basically identical format. I ended up codifying a linter config to make a style guide that basically all existing code already fit into. I remember thinking, this is never going to be so easy again.
Your post makes me think I was right.
My first gig was at a 3 person team, including me. The other two wrote their code in basically identical format. I ended up codifying a linter config to make a style guide that basically all existing code already fit into. I remember thinking, this is never going to be so easy again.
Your post makes me think I was right.
I believe more in tests and documentation now more than ever.
When you have to support legacy code with no docs, no specs, no tests, you change your mind pretty about the value of tests and a good specification.
As a senior engineering manager, I push hard to get good requirements for my team. Its being a sales person with the business side.
When you have to support legacy code with no docs, no specs, no tests, you change your mind pretty about the value of tests and a good specification.
As a senior engineering manager, I push hard to get good requirements for my team. Its being a sales person with the business side.
One thing I would say about the whole "good enough is good enough" mentality is that if everyone has that mentality in a company, your code quality will decline so far that it will be impossible to get anything done in the future. This has happened to my company because ten years ago people had this mentality and it did work for them, getting us a lot of market share and short term success due to high profit margin. However, today we are suffering immensely due to those decisions, losing customers and new hires because no one can get anything done except put out fires due to critical customer issues.
I think a healthy mix of idealists and realists is necessary.. With senior developers representing a good majority of the former.
I think a healthy mix of idealists and realists is necessary.. With senior developers representing a good majority of the former.
I think she covered that by mentioning that architecture is more important as a senior developer. My understanding as a senior developer by what she means is not to focus on optimizing the hell out of code. Too often, people would demand others use the most optimize piece of code, but if the code is only going to be called once or twice, you should focus your time on other things more important.
I think your company is suffering from bad architecture design more than anything else. It seems like everything is tightly coupled with little room for modifications. This probably means those senior developers weren't really senior to begin with. This tends to happen at startups where business is prioritized and people get hired with inflated titles. I have seen that happen in a lot of startups.
I think your company is suffering from bad architecture design more than anything else. It seems like everything is tightly coupled with little room for modifications. This probably means those senior developers weren't really senior to begin with. This tends to happen at startups where business is prioritized and people get hired with inflated titles. I have seen that happen in a lot of startups.
What happened here was different. This is a top 25 Silicon Valley company, thousands of employees.. But with poor software habits. The people who designed the architecture were always under tight time constraints from upper management, so they always accepted the good enough approach.
But you are right! The company is suffering from horrible architecture.. And any attempts to change it are near impossible because of the sheer amount of code and processes that we have. It seems like a never ending battle
But you are right! The company is suffering from horrible architecture.. And any attempts to change it are near impossible because of the sheer amount of code and processes that we have. It seems like a never ending battle
Developers are new factory workers. Pay is good now because industry is expanding and there's not enough of us but it won't be like that forever. And bottom line work is already being commoditized (WordPress ecosystem etc).
From a hiring perspective, the problem is, and will continue to be, the quality of each worker. Although there are a handful of similarities between how the two professions operate, I think that it is unwise to make the factory worker connotation.
The entire idea of a factory worker is that they can be swapped in place by another and the output is maintained to a great extent. This just simply isn't the case in software or really any creative work. Even if we assume two workers have equal skill sets, something that is already dubious due to the importance of cross-domain knowledge in software, the personality one brings to a team will ultimately alter the entire team, sometimes good, sometimes not so. The social dynamic within groups is a critical element and something that cannot be commoditized away like other professions.
As to the point on commoditization within old tech, I can only answer with a "well duh, It's tech!". The goalposts are always moving within this profession. There used to be a whole heck of a lot of jobs in programming super low-level tasks, those are largely gone and have been replaced with new positions. Last year everyone worked on web apps, this year everyone was on mobile apps, next year it's anybody's guess.
The entire idea of a factory worker is that they can be swapped in place by another and the output is maintained to a great extent. This just simply isn't the case in software or really any creative work. Even if we assume two workers have equal skill sets, something that is already dubious due to the importance of cross-domain knowledge in software, the personality one brings to a team will ultimately alter the entire team, sometimes good, sometimes not so. The social dynamic within groups is a critical element and something that cannot be commoditized away like other professions.
As to the point on commoditization within old tech, I can only answer with a "well duh, It's tech!". The goalposts are always moving within this profession. There used to be a whole heck of a lot of jobs in programming super low-level tasks, those are largely gone and have been replaced with new positions. Last year everyone worked on web apps, this year everyone was on mobile apps, next year it's anybody's guess.
That's because our tools are not good enough so what we lack in tools we compensate by individual developer quality.
I spend a lot of time within WordPress ecosystem and I've seen people coming to me with 20K products shops they've built and maintain without a single line of code written.
I've seen companies operating online without having any developments either on contract or in house.
Because for certain simpler scenarios, there's UI based tools you can run your business on.
Sure they come to me because eventually they need something they can't do with tools they use but those are becoming more and more high level jobs.
Web development is pretty much figured out problem. You have legions of repleacable low value developers churning out pages and you have subset of highly paid specialists who can do more advanced things.
But those gazillions web pages are doing their job, they drive sales, improving information quality etc. so I could say digital workers are factory workers of our time.
On certain jobs line is blurry - designers can do basic WordPress but they also can set up MailChimp because machine needs to be humming.
I spend a lot of time within WordPress ecosystem and I've seen people coming to me with 20K products shops they've built and maintain without a single line of code written.
I've seen companies operating online without having any developments either on contract or in house.
Because for certain simpler scenarios, there's UI based tools you can run your business on.
Sure they come to me because eventually they need something they can't do with tools they use but those are becoming more and more high level jobs.
Web development is pretty much figured out problem. You have legions of repleacable low value developers churning out pages and you have subset of highly paid specialists who can do more advanced things.
But those gazillions web pages are doing their job, they drive sales, improving information quality etc. so I could say digital workers are factory workers of our time.
On certain jobs line is blurry - designers can do basic WordPress but they also can set up MailChimp because machine needs to be humming.
Perhaps we are arguing different things. If by developer you are referring specifically to a web-developer, sure they are akin to the a factory worker in that they are, by in large, on the way out. I am arguing the more broad sense of developer as being a substitute for computer programmer.
Finance, accounting, engineering, and many other careers have been around longer, have been commoditized to varying degrees, yet still enjoy good pay.
I think developers will still make good money for decades. I could, however, see an issue with junior developers finding less opportunities in the coming decade. I think there will be less need for juniors and the entry level jobs will be harder to come by. Some of those skills are more easily "commoditized."
I think developers will still make good money for decades. I could, however, see an issue with junior developers finding less opportunities in the coming decade. I think there will be less need for juniors and the entry level jobs will be harder to come by. Some of those skills are more easily "commoditized."
My junior thought: spending 3 days to optimize code to make the UI faster and use fewer resources will be appreciated by managers and users, so win-win.
My senior thought: spend 1 day to SOLVE the problem, and 5 minutes removing the code entirely.
My senior thought: spend 1 day to SOLVE the problem, and 5 minutes removing the code entirely.
No offence to other developers but this is the easiest read of any article I’ve ever read by a developer. I wish I could write like that. I also wish documentation was written by people with that talent.
What I learned as developper and Data Scientist is: either you know what you’re doing and can see the big picture, either you’re walking blindly to a “good enough” solution.
In the first case, I spend most of my time in architectural design and modelization. The implementation phase is rather quick, because everything is well defined and you can write a lot of tests upfront.
In the second case, you’ll discover the big picture by facing the problems while trying to find and implement a working solution.
While getting experienced means how fast can you figure out the big picture.
In the first case, I spend most of my time in architectural design and modelization. The implementation phase is rather quick, because everything is well defined and you can write a lot of tests upfront.
In the second case, you’ll discover the big picture by facing the problems while trying to find and implement a working solution.
While getting experienced means how fast can you figure out the big picture.
I think much of this depends what you are employed to do.
Sometimes it's about making things less complex, which means good practices, code quality, clean code and testing means you can afford a bit more risk.
Equally, sometimes you employed to just get things done, make it work, even fake it till you make it, proof of concepts, minimum viable products, etc.
I've done both, I enjoy both, but they are two different modes of working.
Ultimately the answer is "it depends" and milage may vary.
Quality is a journey not a destination.
Yes, put delivering value above anything else, sometimes that value is quality.
Sometimes it's about making things less complex, which means good practices, code quality, clean code and testing means you can afford a bit more risk.
Equally, sometimes you employed to just get things done, make it work, even fake it till you make it, proof of concepts, minimum viable products, etc.
I've done both, I enjoy both, but they are two different modes of working.
Ultimately the answer is "it depends" and milage may vary.
Quality is a journey not a destination.
Yes, put delivering value above anything else, sometimes that value is quality.
Great article. Related to the “code quality” point, what I have personally realized is that it’s easy to over complicate solutions. Often, a simple solution is better (especially when it is part of a larger, more complex system).
When I was younger, I liked clever solutions to show off my skills. Now I cringe at that. Other people have to read my code. And more importantly, “I” have to read my code tomorrow or next week. I’ve started to really prioritize simplicity. Which is ironically quite hard!
When I was younger, I liked clever solutions to show off my skills. Now I cringe at that. Other people have to read my code. And more importantly, “I” have to read my code tomorrow or next week. I’ve started to really prioritize simplicity. Which is ironically quite hard!
Good writup.
>Imagine 50+ comments on your PR with all the semicolons you missed!
Depends. You should have a style guide and it should document what the expectation is. If it was decided that semicolons are mandatory, then code review should be failed. If they are optional than the code reviewer shouldn't flag it. The alternative is to use a linter/formatter and either auto-fail during a pull-request or have the tool fix it up.
>Imagine 50+ comments on your PR with all the semicolons you missed!
Depends. You should have a style guide and it should document what the expectation is. If it was decided that semicolons are mandatory, then code review should be failed. If they are optional than the code reviewer shouldn't flag it. The alternative is to use a linter/formatter and either auto-fail during a pull-request or have the tool fix it up.
> So imagine my surprise when I showed up at my first day on the job at a startup and found no tests at all. No tests in the frontend. No tests in the backend. Just, no tests.
> Nada. Zip. Null. Undefined. NaN tests.
On my current project I have 100% test code coverage. Which I believe is quite unusual. But I am pretty sure that if I give a talk about how I did it, most people will be horrified.
On my current project I have 100% test code coverage. Which I believe is quite unusual. But I am pretty sure that if I give a talk about how I did it, most people will be horrified.
I worked on a project that achieved 100% code coverage and still had loads of bugs. That’s precisely when I lost all faith in TDD.
Thoughtful and deserving of HN front page attention.
I agree. Title doesn't matter. There is so much title inflation in the industry today.
For me, becoming a senior developer has allowed me to see code more objectively than before. Instead of following convention to the T, I can now look at code and make my own judgement whether to follow the convention. It's great to have the sense of relieve.
For me, becoming a senior developer has allowed me to see code more objectively than before. Instead of following convention to the T, I can now look at code and make my own judgement whether to follow the convention. It's great to have the sense of relieve.
[deleted]
[deleted]
Over the course of my career, I've gone from deploying via scp, to svn-up/git-pull, to every variety of actual deployment pipeline imaginable with dedicated dev-ops teams. Now I'm the only engineer at a tiny 501(c)(3), git-pull straight from production again, and have never felt more free.
I love the uncluttered ui for the site you work for https://sumup.com/ sticks the message to the potential customer instead of shoving lots of blog/jobs/other links all over the place as in the top menu.
good article, I agree with most of the things.
However code reviews that only have comments about code style are kinda useless in my opinion. I rather get 50 comments about how to improve my code instead of missed formatting. (which can be also done automatically)
That is the exact point the article is making. When you are junior you think that code style is the most important thing but it isn't. (Also it can be handled automatically as you say)
> "Not everyone will become senior during their career"
This. So much this. I didn't realise that until a little while ago but when I did it made me realise I need to understand actually what make someone a senior. It's not just an automatic progression.
This. So much this. I didn't realise that until a little while ago but when I did it made me realise I need to understand actually what make someone a senior. It's not just an automatic progression.
Absolute truths passed on by my various line managers:
- Assumptions are the mother of all fuckups.
- The optimal number of people in an organisation is 3. At 4 you start losing efficiency. At 80,000....
- The more you progress in the hierarchy, the more you realise it is the same idiots at every level.
- Assumptions are the mother of all fuckups.
- The optimal number of people in an organisation is 3. At 4 you start losing efficiency. At 80,000....
- The more you progress in the hierarchy, the more you realise it is the same idiots at every level.
We’re so far behind everyone else (AKA “tech FOMO”)
This one hit strongly for me because I didn't realize it until reading this...
I am sure our CTO and PM are tired of me pushing for the latest tech I read about on here all the time. I will hold back a little more from now on.
This one hit strongly for me because I didn't realize it until reading this...
I am sure our CTO and PM are tired of me pushing for the latest tech I read about on here all the time. I will hold back a little more from now on.
> I read “that orange website” all the damn time.
Yeah, don’t take the “orange website” too seriously.
Yeah, don’t take the “orange website” too seriously.
A good plan violently executed now is better than a perfect plan executed next week. - Patton
It's much better to get something, anything, on the screen and working than an elegant design constantly refined but never put to actual use.
It's much better to get something, anything, on the screen and working than an elegant design constantly refined but never put to actual use.
Not just "anything". Patton did say a "good" plan. A bad plan can tank you just as much as elegant design that isn't used.
"It's about the code." That is probably the biggest untruth I though when I was a new developer (I dislike the term "junior").
The truth: "It's not about the code, it's about the people."
The truth: "It's not about the code, it's about the people."
i think now more than ever, there needs to be a bridge mindset between technical and non-technical. i learned that very early on, and even spent some time in a customer-facing, non-technical role to hone my bridge mindset. the ability to have empathy for the end user, and everyone else upstream who will touch your logic, is paramount and takes care of a lot of issues.
it's up to us as technical professionals to care about both the "what" and the "how". the ability to pan in and out on a particular need was learned early on and i cannot be more thankful of that.
it's up to us as technical professionals to care about both the "what" and the "how". the ability to pan in and out on a particular need was learned early on and i cannot be more thankful of that.
Some of us technical people like to be client-facing. The key is to make room for us to do that. Let us handle the client/user and then take meetings with us so we can filter what's appropriate to you.
The biggest problem with "technical people" is the desire to retreat to a pair of headphones and not communicate with anyone all day. Set aside some consistent portion of your day where that's the only time you'll take meetings and we'll work around your schedule.
The biggest problem with "technical people" is the desire to retreat to a pair of headphones and not communicate with anyone all day. Set aside some consistent portion of your day where that's the only time you'll take meetings and we'll work around your schedule.
I agree. I enjoy speaking to prospects and clients, but I know not everyone feels the same way. I would say instead of letting technical people handle the client/user, it should be done in a collaborative way. Filtering shouldn't be necessary as that has the potential of keeping possible problems/solutions in the dark.
Technical and nontechnical people should collaborate face-to-face on a daily basis. That includes customer interactions.
Technical and nontechnical people should collaborate face-to-face on a daily basis. That includes customer interactions.
As you get older, the thing you unlearn is that there are no absolute truths.
The only thing to do when you implement a linter is fix the 800 errors it generates. It shouldn’t take long. That’s absolutely the right thing to do, and I’d happily back anyone on my team who does that.
How can you define seniors as pros? I know some senior devs that suck at programming, still coding in Perl using Notepad++ and their systems are full of bugs.
Perhaps the reason for "nobody writes tests" in the real-world isn't primarily because of time/cost, but because virtually no real potential bugs are testable. If you're writing a JPEG encoder or database model handler, yes, you can test that all day, but those things already exist and are well-tested for you. But if you're designing retail software or a web app, there are 2^10000 things that can go wrong, so most companies ignore automated unit testing in favor of human quality control.
This is all wrong. When you have enough people working on a codebase such that not everyone knows everything about it, tests are a great way to document the behavior. They're much better than something like a wiki, in fact, because nobody actually keeps that kind of documentation up to date.
I'm not arguing that tests are useless. I'm arguing that tests are usually impossible. I invite you to suggest a test for https://github.com/VCVRack/Rack for example that could either 1) have prevented a bug, or 2) document the software's behavior.
You only have 2^10000 if you have bad boundaries and overcoupling of your subsystems. Thus another benefit of unit testing is validating your architecture: bad architectures are inherently difficult to unit test.
>bad boundaries and overcoupling of your subsystems
And that's the overwhelming majority of ways to make money with software. Think of every video game, desktop application, and mobile app that people purchase. What you call "bad boundary" isn't bad at all. The customers just expect the software to do 2^10000 combinations of possible things across N platforms on M hardware and integration with P external services. Imagine if you emailed a company's tech support saying that the CAD software you bought doesn't work with your Nvidia 1060, and they responded "sorry, that makes our sybsystems overcoupled".
And that's the overwhelming majority of ways to make money with software. Think of every video game, desktop application, and mobile app that people purchase. What you call "bad boundary" isn't bad at all. The customers just expect the software to do 2^10000 combinations of possible things across N platforms on M hardware and integration with P external services. Imagine if you emailed a company's tech support saying that the CAD software you bought doesn't work with your Nvidia 1060, and they responded "sorry, that makes our sybsystems overcoupled".
> Early in your career, you can learn 10x more in a supportive team in 1 year, than coding on your own (or with minimal feedback) for 5 years.
Spot on!!!
Spot on!!!
I've been doing dev work for 20+ odd years now, and I suppose I can relate to many of these realizations. A young developer's framework is full of sharp polemics that soften over time as we scrape against them through experience. It's definitely something I look for in junior devs - a few strongly held opinions and a willingness to back them up by referring to some coherent "moral" framework - as long as this does not descend into technical dogma or dismissal of other perspectives.
If I were to step back and try to characterize the growth in my understanding of software development in a single general statement, putting aside all the hard-tack technical experience, it's this:
I am beginning to understand the subtle and complex delineation between _good_ and _useful_, and the role that execution plays in that - with all it's myriad parts: prioritization, management, technical risk mitigation and hypothesis validation, consensus building on technical direction, post-hoc validation, etc. etc.
And usefulness has a lot of facets in execution: not just technical but social. A good project and good idea might come to nothing if you are oblivious to obtaining some organizational mandate for it, and it gets sidelined due to shifts in priorities. If this happens, it means a misstep was made earlier: either the project should never have been started at all - due to awareness of upcoming priority changes, or you should have done the organizational consensus building to ensure that the work had the runway it needed to complete.
The same goes for technical consensus among implementors. Sometimes this can be avoided by giving clear mandates to trusted individual leads, but come complex projects really need the input of multiple senior members.
I'm starting to find lately that many of the contributions I'm most proud of are the ones where I come to firm conclusions on what work _not_ to do: concluding that certain tasks that were good but not useful enough, or determining ahead of time that certain planned implementation paths are actually not going to deliver what we might have expected them to, and thus we should scrap that idea. It has saved inordinate amounts of time that would _otherwise_ have been wasted.
The challenge for me has been reconciling this new understanding with my old methods for evaluating my own performance. I know these days, within reasonable bounds of arrogance, how to write decently complex software and understand it. As I move on to considering these higher level concerns, I find that I'm asking myself whether that opportunity cost is worth it: "I _could_ be spending time writing good code right now, instead of analysis and reports and meetings and planning. Is this new activity of mine _useful_?"
I'm still building my internal model for measuring my effectiveness in this new domain.. but it's clear that it's a profoundly impactful and worthwhile multi-factor optimization problem to tackle.
If I were to step back and try to characterize the growth in my understanding of software development in a single general statement, putting aside all the hard-tack technical experience, it's this:
I am beginning to understand the subtle and complex delineation between _good_ and _useful_, and the role that execution plays in that - with all it's myriad parts: prioritization, management, technical risk mitigation and hypothesis validation, consensus building on technical direction, post-hoc validation, etc. etc.
And usefulness has a lot of facets in execution: not just technical but social. A good project and good idea might come to nothing if you are oblivious to obtaining some organizational mandate for it, and it gets sidelined due to shifts in priorities. If this happens, it means a misstep was made earlier: either the project should never have been started at all - due to awareness of upcoming priority changes, or you should have done the organizational consensus building to ensure that the work had the runway it needed to complete.
The same goes for technical consensus among implementors. Sometimes this can be avoided by giving clear mandates to trusted individual leads, but come complex projects really need the input of multiple senior members.
I'm starting to find lately that many of the contributions I'm most proud of are the ones where I come to firm conclusions on what work _not_ to do: concluding that certain tasks that were good but not useful enough, or determining ahead of time that certain planned implementation paths are actually not going to deliver what we might have expected them to, and thus we should scrap that idea. It has saved inordinate amounts of time that would _otherwise_ have been wasted.
The challenge for me has been reconciling this new understanding with my old methods for evaluating my own performance. I know these days, within reasonable bounds of arrogance, how to write decently complex software and understand it. As I move on to considering these higher level concerns, I find that I'm asking myself whether that opportunity cost is worth it: "I _could_ be spending time writing good code right now, instead of analysis and reports and meetings and planning. Is this new activity of mine _useful_?"
I'm still building my internal model for measuring my effectiveness in this new domain.. but it's clear that it's a profoundly impactful and worthwhile multi-factor optimization problem to tackle.
But seriously, put in your damn semicolons.
A paean to normalization of variance.
Most of the time legacy code and technical debt appearing on same project
Learned as a junior: results matter
Learned as a senior: stories matter
>I read “that orange website” all the damn time.
Is she talking about HN?
Is she talking about HN?
I must say this is a very well written blog post.
I just started my first job as a junior-mid_level dev last week, my team is really awesome and I've been learning a lot. I'm the only junior dev on a team with 3 mid to senior devs, so there's lots to learn.
1: A great quote from one of the most senior developers I look up to town said this: a developer who's been developing for 1 year can have _far_ more experience than someone who's been doing it for 3 years. I find people who introduce themselves as "developer for 15 years" aren't those types, rather it's the ones that show innovation.
Another quote is this - to become a better developer, you need people at the same level as you, more experienced, and less experienced. So I've taken it upon myself to mentor junior developers in town. Other ways I've learned is by talking about technical challenges from multiple developers in multiple companies in my surrounding region, doing technical & lightning talks, and participating in hackathons.
2: I wasn't entirely surprised by how little testing there was even at companies that have been around for a 3+ years, I had learn that most companies in my area (even the ones that have great developers) - code test coverage was poor. There is an opportunity cost in testing something that might change later. As kent dodds put it, do some tests coverage on core features, but have integration tests
3: I think working with legacy codebases is a great way to learn. The codebase shows a story about how the scope of the project changed, how workarounds were made to meet client expectations in short turn around time, etc. These things you don't learn on your own. Being forced to break something down and build it into a better version is rewarding, so long as it's not everything you do.
4: My first code review was more informal, it was more pointing out everything I didn't consider when implementing a feature. E.g deleting old unused code, formatting things semantically and expressively, etc. Was still setting up my dev env so there were a few grammatical errors that didn't match eslint styleguides, but we had test runners for those.
5: Documentation to me has always been important, but forcing it upon others as a way to bookmark something I avoided. I think it's far better to just notate on a piece of paper your interpretation of how the code works, or write your own documents in Confluence/team-wikis so your senior dev can understand your interpretation of how things work. As the new dev on my team in a year, documentation was out of date and each dev only knew specific parts of the codebase, so I've been updating how everything works from a eagles-eye perspective. Those notes have a lot of value to the next dev that gets hired, because they come from a clean slate like yourself.
I also think, documentating your pseudo-code inside of tickets is important. I've learned the hard way from getting fired at a previous job many years back - you need to actively show your team what you do. Documentation is the lowest hanging fruit, you need to think about what you're going to say in your daily standup tomorrow, communication is essential
6: For me technical debt is really being able to identify where the debt lies. For instance, rails and laravel has well documented magic, but the path less traveled needs to be understood. My rule of thumb is if I'm going to write less-than-ideal code, it needs a comment block indicating why I did so. Don't push code you yourself don't want to read 6 months later
7: In regards to seniority, I think the best developers know they are junior in other areas and are multidisciplined in other fields besides programming. I've learned a lot of great wisdom from developers in my city's slack channel just by seeing conversations unfold. I know some first year developers whom I already consider senior, and some developers who've been doing this longer who I do not.
I think the most important thing I've learned in these 2 weeks in my first dev role, you can be a mediocre dev who just copypastes things and still be a great asset to any team. There's a lot of value in just documentation & communication alone
Other things I learned - you can bother your senior dev if they just sat-down or stoodup from their desk, or if their headphones are off. But experiment with communicating asynchronously in slack and synchronously in person and see what works and what doesn't - even if they sit right next to you.
At the crux of everything, it's important to have a certain growth mindset. I embrace a japanese methodology called LEAN. Other things - being okay with self-humilation is a great way to learn. Other things - force yourself to take breaks by only using small water bottles or none at all.
Also, make sure you say hello to everyone in the morning, my office is 20+ mechanical/electrical/civil engineers/designers, I make sure to say hi to them. I take the longer-route of walking through the frontdoor every morning, my boss makes fun of me for that. Give the gift of giving to others in the community, it reflects well on yourself, my team already had heard of me despite never meeting me b/c of how active I am in the local tech community. Rubber duckies are good inexpensive programmer gifts.
1: A great quote from one of the most senior developers I look up to town said this: a developer who's been developing for 1 year can have _far_ more experience than someone who's been doing it for 3 years. I find people who introduce themselves as "developer for 15 years" aren't those types, rather it's the ones that show innovation.
Another quote is this - to become a better developer, you need people at the same level as you, more experienced, and less experienced. So I've taken it upon myself to mentor junior developers in town. Other ways I've learned is by talking about technical challenges from multiple developers in multiple companies in my surrounding region, doing technical & lightning talks, and participating in hackathons.
2: I wasn't entirely surprised by how little testing there was even at companies that have been around for a 3+ years, I had learn that most companies in my area (even the ones that have great developers) - code test coverage was poor. There is an opportunity cost in testing something that might change later. As kent dodds put it, do some tests coverage on core features, but have integration tests
3: I think working with legacy codebases is a great way to learn. The codebase shows a story about how the scope of the project changed, how workarounds were made to meet client expectations in short turn around time, etc. These things you don't learn on your own. Being forced to break something down and build it into a better version is rewarding, so long as it's not everything you do.
4: My first code review was more informal, it was more pointing out everything I didn't consider when implementing a feature. E.g deleting old unused code, formatting things semantically and expressively, etc. Was still setting up my dev env so there were a few grammatical errors that didn't match eslint styleguides, but we had test runners for those.
5: Documentation to me has always been important, but forcing it upon others as a way to bookmark something I avoided. I think it's far better to just notate on a piece of paper your interpretation of how the code works, or write your own documents in Confluence/team-wikis so your senior dev can understand your interpretation of how things work. As the new dev on my team in a year, documentation was out of date and each dev only knew specific parts of the codebase, so I've been updating how everything works from a eagles-eye perspective. Those notes have a lot of value to the next dev that gets hired, because they come from a clean slate like yourself.
I also think, documentating your pseudo-code inside of tickets is important. I've learned the hard way from getting fired at a previous job many years back - you need to actively show your team what you do. Documentation is the lowest hanging fruit, you need to think about what you're going to say in your daily standup tomorrow, communication is essential
6: For me technical debt is really being able to identify where the debt lies. For instance, rails and laravel has well documented magic, but the path less traveled needs to be understood. My rule of thumb is if I'm going to write less-than-ideal code, it needs a comment block indicating why I did so. Don't push code you yourself don't want to read 6 months later
7: In regards to seniority, I think the best developers know they are junior in other areas and are multidisciplined in other fields besides programming. I've learned a lot of great wisdom from developers in my city's slack channel just by seeing conversations unfold. I know some first year developers whom I already consider senior, and some developers who've been doing this longer who I do not.
I think the most important thing I've learned in these 2 weeks in my first dev role, you can be a mediocre dev who just copypastes things and still be a great asset to any team. There's a lot of value in just documentation & communication alone
Other things I learned - you can bother your senior dev if they just sat-down or stoodup from their desk, or if their headphones are off. But experiment with communicating asynchronously in slack and synchronously in person and see what works and what doesn't - even if they sit right next to you.
At the crux of everything, it's important to have a certain growth mindset. I embrace a japanese methodology called LEAN. Other things - being okay with self-humilation is a great way to learn. Other things - force yourself to take breaks by only using small water bottles or none at all.
Also, make sure you say hello to everyone in the morning, my office is 20+ mechanical/electrical/civil engineers/designers, I make sure to say hi to them. I take the longer-route of walking through the frontdoor every morning, my boss makes fun of me for that. Give the gift of giving to others in the community, it reflects well on yourself, my team already had heard of me despite never meeting me b/c of how active I am in the local tech community. Rubber duckies are good inexpensive programmer gifts.
[deleted]
Epoché
Interestingly, some of these absolute truths are absolutely true at larger (50+ devs, or so) companies because forward progress can't be made otherwise. System not documented? Might as well not exist at all. Code is not tested? Well, then nobody really knows if it works or not after even the most insignificant and peripheral changes. People don't treat code quality as a priority? Welcome to days/weeks/months of yak shaving to fix even the simplest issues. Good at communication but can't code worth a damn? Consider becoming a manager, not a "senior developer".
[deleted]
I disagree with the documentation one. I really think developers need to focus a whole lot more on documentation, possibly prioritizing it over code.
In fact, I think there should be something like a documentation driven development, where first devs change the description of what code should do, and then change or add the tests, and then finally write the code.
In fact, I think there should be something like a documentation driven development, where first devs change the description of what code should do, and then change or add the tests, and then finally write the code.
That's the kind of talk I always hear from mediocre devs once they reach their first management job.
[deleted]
Learned as junior: If you report an OS bug or some other deep problem, seniors will not believe you and assume you're making excuses for your own bugs and lack of understanding.
Understood as senior: If a junior programmer tells me they found a system-level bug, I won't believe them and will tell them to go figure out what's wrong with their code.
Learned as junior: Legacy code is hard to read.
Understood as senior: Legacy code that I wrote myself is hard to read.
Learned as junior: Technical skills matter most.
Understood as senior: Communication skills matter most.
Learned as junior: New tech solves old problems.
Understood as senior: New tech creates new problems.