>It is very common, especially among novice developers, to be proud of the number of line of code their application has.
My experience has been the opposite. Novice developers tend to be proud of how terse and dense their code is, and optimize for minimizing line count.
I also disagree with that author's views on this point. For example: "Simply put, it means “the less, the better”" - No, it isn't.
In my career I found that maintaining unsexy, and maybe a little verbose code is never the problem. Usually that code tends to be more easily understandable to even junior developers and therefore is less prone to bugs being introduced because developer made the wrong assumptions on what the code was doing. Code that is too clever for its own good is where bugs tend to occur.
My take on it is that all software developers novice or otherwise try to write simple, clear code.
For some(especially novices) that means plodding, low abstraction code, so that all the details are visible. This makes for longer code. Others see high abstraction code as the cleaner simpler code because the abstractions hide what they see as irrelevant details, which makes for terse code.
“the less, the better”
“the more, the better”
Tautologically both are incorrect when pursued farther than is prudent, and "the right amount, the better". Unfortunately no one really agrees on what "the right amount" is or we wouldn't have to discus different definitions and strategies to reach "the right amount".
Part of learning any new technique is overusing it to see what its limits are.
When people first start coding they're trying to get machines to do things. They have to learn the techniques of making code for other humans. To them it's making things verbose and adding tons of comments because that's better.
Meanwhile, they're usually learning to plan for future code needs and make their code flexible.
But part of learning to use those techniques is overuse. So that means code gets gold-plated, baroque, byzantine, and needs a novella of comments to explain its magnificence to future developers so that they use it right. Time to trim it back. Less is more.
Verbose code is one thing but multiple adjoining layers of abstraction, or excessive modularization can both make maintaining code very difficult as well. Both dense and bloated solutions had goals other than doing the simplest thing that might possibly solve the immediate problem. That is the only worthy goal, it ensures maintainability due to its simplicity and any extensibility loss is offset by that simplicity. Most of the designed in extensibility I've seen predicted the wrong sort of extension that would be needed anyway.
I believe the author would agree with you, his last bullet point is write for humans not for machines. When he says write less code, I believe he means favoring simpler architectures, saying no to
features & tools until you absolutely need them & even finding no-code solutions. Not taking verbose code & making it less readable by shortening it.
I think the author is referring to the mentality of "I wrote my way into this mess and dammit I'll write my way out!"
That is to say, novices can tend to pile onto a solution with hacks and special cases instead of examining why their abstraction requires so much special casing.
I think the code golf you're talking about is a different (but not exclusive) thing.
> My experience has been the opposite. Novice developers tend to be proud of how terse and dense their code is, and optimize for minimizing line count.
I would agree with that. But then again, it isn't entirely incompatible with the cited quote. That is, at different times in their careers, developers may tend to do different things.
In any case, I think I understand the original quote as something I have indeed seen somewhat frequently in large projects. It seems somewhat common, from my experience at least, that people -particularly "not-so-good developers"- involved in large projects tend to assert how large/important the project in fact is, by mentioning LOCs. "This is a very large project... It's about 5.5MLOCs or so. It will have grown a bit since we last counted."
Write as little code as needed to complete the task and as much code as needed to be understood. At the same time.
Both incredibly dense and incredibly verbose code can become maintenance headaches. You want it short enough that it can be contained in your head, but long enough that the steps are obvious.
I liken it to the scene in Return of the Jedi where Han is instructing Chewie to fly close, but not too close.
> My experience has been the opposite. Novice developers tend to be proud of how terse and dense their code is, and optimize for minimizing line count.
I think it's both. There's a sense of accomplishment that goes along with both accomplishing some small task with minimal code, and also for having written a somewhat large chunk of code for a project. Both have their place, as succinctness has it's place, and it's natural to look back and feel proud of a lot of work. It's just when they aren't tempered by the experience to ask whether that terseness came at a cost that wasn't worth it or whether that project is much larger than it needs to be for the task accomplished that it ends up being detrimental.
I discovered IRC as a teenager in the 90s, and soon learned SMS-speak for rapid messaging. I was proud of how quickly I could write if I just wrote "u r" instead of "you are"... This was cool! In chatroom arguments, being able to belt out more sentences faster was better!
But as my typing improved, I realized the above was a childish optimization. Real skill was able to write out correctly-spelled sentences just as fast. I then saw the SMS-speak as immature shortcuts.
This realization carried over into code: good code is the clear, adequately verbose (but appropriately concise) kind. Code that tries to be overly-clever (of the "code golf" kind), was to be viewed with suspicion.
The author lists the habits of *bad* developers as: (1) Never assume there is a bug in your code, (2) Write code without reasoning, (3) Lack assertiveness, (4) Take pleasure in writing more code, (5) Write for machines, not humans.
So the author advocates for less code, but written to be used and maintained by other people.
My friends and I used to joke about how verbose variable and object names can be in an enterprise setting. But the longer I have worked as a professional developer the more I appreciate the long and 'exactly what it says on the tin' names. In almost every circumstance developer time is more valuable to the company than some clever code that 'saves' CPU time.
> My experience has been the opposite. Novice developers tend to be proud of how terse and dense their code is, and optimize for minimizing line count.
Depends on the culture. A lot of offshored programmers will report their "performance" as number of lines written. With the expected results...
2) Or avoid writing factories that produce factories, abstractions upon abstractions that never get the payoff since the abstraction only gets used for a single (or a handful) of cases ever. When you write abstractions, make sure that in next 10-20 years its going to get its money's worth by taking advantage of it. There are always some exceptions but most of the time I've seen code that has no defense for all the bloat.
3) The best code is the code that you don't write. In this case "the less, the better" indeed.
So I can see multiple meanings of "less, the better". Also, my experience matches the author - new developers are mostly proud of number of lines than cleverness.
"Simply put, it means “the less, the better”" was referring to the principle of "via negativa", not necessarily to code.
Maybe I conveyed the wrong meaning on this sentence. I don't think that less code is better. I believe that the more code you have, the more potentially breaking parts you get. However, the right amount of code is a function of your deadline, team, goals, budget and whatnot.
In any case, it's nice to have principles as a beacon during your development, so you don't get lazy and fool yourself. But by no means they are written in stone and every attempt to summarize an absolute truth will be shallow.
> I also disagree with that author's views on this point. For example: "Simply put, it means “the less, the better”" - No, it isn't.
This is one piece of developer lore that’s actually backed by some research. [1] Like it or not, there is a correlation between lines of code and bug count.
Maybe I misread him, but I read it as "it is better to have just the right, critical set of features", instead of "adding more bells and whistles will always makes it better!"
I know from my own code, that whenever I introduce too much flexibility, I invariably end up with fragile complexity, and using it to shoot my feet from various angles.
And I have also met a colleague or two who so far haven't reached the same conclusion, only the fragile complexity part (i.e. they still see it as a positive thing.)
Yup... I find this with swift developers they love to write code that is just a series of : ? ! type symbols to do what should be 3 or 4 lines of readable code into one line of unreadable code.
The principles in this article seem paradoxically conflicting, especially this one (“[don’t] Take pleasure in writing more code”) and “[don’t] Write for machines, not humans”
Inherently, more code means more chances to explain what it’s doing to other humans, so shouldn’t more code be better?
Obviously not, so I take these two principles in tandem as “write as much code as is needed to accomplish the task effectively and explain how it works, but no more than that.”
Squishy, but I think this article as a whole does a decent job of addressing your concerns.
I know where you are coming from and I agree on a certain level, but I think this is too specific to your case (large teams, high fluctuation, lots of juniors)
The more general approach would be to write code with coworkers/audience in mind.
In some environments or projects it might be more effective to write in a way that is harder to grok (requires more work to understand) but is ultimately more tailored to a specific outcome, may that be performance, extensibility, security or what ever.
Have you ever dealt with seriously verbose code? One 10,000 line file with maybe three functions or methods? Setting and resetting the same variables; perhaps introducing new ones kind of randomly? From a programmer who uses essentially one control structure, a while(true) loop with a test and break somewhere in the middle of the body? (Actually, the last is a separate issue, but things like that always add to the fun.)
Funny that point 4 and 5 both make sense alone but are fairly contradictory when applied together. Juniors can barely understand why they are both very important.
It's with experience that you learn to write less small dumb code, and write more longer smart/debuggable code.
In my short career, the worst code was always the one made by the overly experienced CTO that insist on doing everything in a one liner.
+1, came here to say this. The comprehensibility of the code matters way more than the length. It’s not like the bugs sneak in once every 50 characters typed.
As I’ve gotten more experienced, my code has gotten less fancy and more verbose. A single terse expression is broken out into 3 or 4 statements, defining variables that capture and name fragments.
My experience is somewhere in between. Many novice developers are proud of how few lines of code their solution is although it’s really just 2 lines of glue code masking 300mb of dependencies. When you point this out they come back with some bullshit like:
Hubris, to the point where everyone around you must be a moron.
I've seen very talented developers fall prey for that one. They seem to fit the pattern of your typical "hacker" type that grew up spending all their youth on coding, and thus binding a lot of their identity and self-worth to their coding abilities.
They blaze through college, being extremely competitive among their peers, and are often among the "go-to" students in class, which only boosts their ego even further.
Then they join the workforce, and find themselves having to work with other people - and they hate it. Any hint of criticism is taken deeply personal, like a sledgehammer to their self-worth. Tips and tricks from others are equally bad - who are they to teach you anything? After all, you've been banging out code and reading books since you were 9.
Code review is like walking on eggshells for the others - they know you'll roll your eyes, chuckle and snort, and just shoot down any incoming comment.
If only you didn't have to work with all these morons around you - the very people that are slowing you down. Move fast and break things, isn't that the motto?
I've seen people reading about CQRS, Clean Code, Hexagonal Architecture, Event Bus, all these "good practices" published by celebrities... and after some time these people believe "they are right" because they know these patterns and because they apply them every time code needs to be written. It's difficult to reason with them; the conversation usually goes this way:
- Joe: We should use Hexagonal Architecture in our new system because Alistair Cockburn knows what's best
- Me: I think we don't need it? Past experience in other projects of ours says we can handle this new system without HA
- Joe: I don't think you know better than Alistair Cockburn, so let's stick with HA
Very common trap. Most of us grew up with a natural enjoyment of programming, so it’s easy to lose sight of the fact that our job as engineers isn’t to produce more and more code. Our job is to deliver results, not lines of code.
This often manifests as developers or entire teams that can’t stop rewriting, refactoring, and rearchitecting code that is already good enough. They might want to rewrite their otherwise working service in Rust because Node.js is no longer popular, or rework the stable React app to use hooks, or fork and maintain a popular open-source project because they think they can improve it. They prefer to write generalized solutions or frameworks from the start instead of writing a specific one-off solution to get the job done. Or maybe they just have perfectionist tendencies and struggle to submit that PR until they make just one more improvement.
This isn’t unique to developers, of course. My last company had a major problem with UI/UX designers who could never finalize their designs. We lost countless months to endless iterations and tweaks. Part of the problem lies with management, of course, if they’re not enforcing actual project deadlines and end times.
I once had the misfortune of working at a company whose rockstar developer was a bad developer. He could crank out reams of working code as easy as breathing it seemed.
My misfortune was being assigned to take over one of the projects he threw together. My god, what a mess. He literally had 10 to 20 boolean flags in every pages long functions so that it was extremely difficult to tell what path the code would take under what circumstances. I got fired because I couldn't understand the code enough to enhance it. I was judged inadequate.
A couple of years later I had lunch with the developer who took my place. She told me what code she was working on. When I casually said "Oh, that spaghetti code is still used?" she let out a big sigh. She thought the problem was with her and finally someone had come along to call out the crappy code this "rockstar" was foisting on everyone.
My manager showed me where I fall on the company-wide distribution of quality(based on issues attributed to my code), and quantity(based on logical lines of code committed). I was near the top for quality, and near the median for quantity. My project had been fairly complex, involving the joining of two already complex systems that handle a wide range of configurations and had their own fair share of bugs that I had to figure out. I held my tongue when they said that I should work on increasing my output.
Author here. So you guys are the reason of the huge spike on my website today?
I should mention that the "rules" there are completely opinionated and reflect what I understood as the biggest problems I had (and still have) as a software engineer.
Also would like to clarify that "via negativa" is a general principle, but of course won't work all the time. As a matter of fact, I refrain myself from excessive modularization whenever I can. In the end, software development is about delivering the biggest value, in less time, without compromising quality and maintainability (or at least being aware of the costs).
A nice side-effect of this semi-virality is that I get to read a lot of nice additions to the original 5 points. This post is calling for a sequel...
I had a boss who went with, "Always assume the bug is in our code." Which wasn't too bad, except for the time he wouldn't let us tell the hardware partner they probably had a bug until we could definitively prove that it was their problem and not ours. Took us a few months to produce a reliable test case for the error (consistent failures and not sporadic ones) and shifted the entire project schedule (not just us) right. He just didn't trust us lowly CS types.
This one is interesting: "Take pleasure in writing more code".
I agree with the author's reasoning that the number of lines of code you write is meaningless and not something you should hold up with pride, but there is a flipside to that: when you get to a certain amount of experience, code verbosity is usually a good thing.
At some point when learning, many programmers become good enough at thinking in code that they become able to express everything in incredibly terse one-liners. This is when they start using ternary operators everywhere instead of if statements, or very obscure functional map/reduces instead of simple for loops.
Being able to write like this is obviously good, but that doesn't mean you should do it: just because you can cram everything into one line/statement, doesn't mean you should. This gig is not just about writing clever code, it's about writing code that others can read (as well as yourself, six months later) and reason about and debug easily.
Writing understandable code is not always the same as writing more verbose code, but the two are certainly correlated.
The #1 way to become a bad developer is: stop caring.
- Stop caring about understanding what you are doing.
- Stop caring about the quality of your deliverables.
- Stop caring about understanding how things work.
- Stop caring about finding better ways of doing things.
- Stop caring about learning.
- Stop caring about what you have learned and how you can use it.
There are many factors that will make tempt you stop caring, but you should resist them and persevere. One of such factors is: mediocre jobs, mediocre leadership.
If you stop caring, you'll become unemployable in a few years, and any advantage you had over younger developers will go away.
In my experience, a junior developer is one that
1. Thinks through problem very linearly, leading to very long and complicated functions.
2. Only thinks about the happy path. They don't validate inputs or analyze what could go wrong and handle those cases.
I can't tell you how many bugs I've fixed because programmers write code that only works if everything goes exactly the way they expect.
Please enlighten me here, in the past we were obsessed with design patterns and tried to make code as modular as possible and we were proud if our code worked for 5-10 years.
nowadays, 2 biggest advise I get from articles and books are: (1) make code as readable as possible (2) write code so it is easy to remove the code and re-write. basically advising me to write such methods: StoreUserDataAndFetchDetailsFromOauthProvider, instead of some fancy flows
world is moving very fast and time spent on making code modular with design patterns seems not worth it (I am spending my last 6-8 years in startups).
most of my code is verbose and doesn't contain design patterns, am I that bad developer?
"How to be successful" screeds like the one cited in this article from the Berkshire Hathway ghoul always seems to leave out a crucial step: "Come from a well-off, well-connected family".
I would add "focus on how your progress looks in the eyes of the stakeholders".
I lost count how many times I had to fight over doing actual work and coming clean on how much is really done versus making the result only appear finished and knowingly merging buggy code.
Stakeholders put pressure because of course they do. That doesn't mean lying to them is a sound tactic. It's much better to negotiate a reduction of scope than pretend you've delivered only to later have them, or worse - the users - discover the truth.
Step 1: Constantly suggest very stupid ideas with a complete unawareness of the greater context, just because the thing youre suggesting is something you're good at, so you just recommend it blindly
Step 2: Don't ask questions, don't know how to communicate
Step 3: Take ideally 1 day or more to respond to clients
On the taking pride in LOC counts I really enjoy the opposite. Especially rewarding is blowing up a bad manager who things LOC increase equals productivity. So much fun to report I contributed -10,000 LOC in the last month by careful refactoring and reusability.
I could see this being a "good developer" trait too. For example, writing programs that are designed to be easily consumed by other programs. Humans might like a nicely formatted HTML page, but machines like plain text output.
The more code/less code debate can be seen in language learning. Initially, you're happy you can use a large amount of language well. Later, you're happy if you can articulate yourself in as few words as possible.
I would prefer a developer who can work with a large amount of code. I would prefer, even more, a developer who can write the same thing with less code. Generally speaking, a developer doesn't gain the ability to the do the latter without first doing the former.
And there's an annoying phase in the middle where "less code" is condensed code.
I don't know about this. Some of the junior devs I have had to work with modularize everything into, in this case, components to be used by react just to save a line of code or two. Understanding what is happening on the page requires drilling down through multiple file/function jumps.
I cannot stand that approach. The real tell is that none of them have ever used a raw html element in any of the code they have written. It is more or less custom components on top of something like material-ui or bust! Yikes.
[+] [-] macspoofing|4 years ago|reply
My experience has been the opposite. Novice developers tend to be proud of how terse and dense their code is, and optimize for minimizing line count.
I also disagree with that author's views on this point. For example: "Simply put, it means “the less, the better”" - No, it isn't.
In my career I found that maintaining unsexy, and maybe a little verbose code is never the problem. Usually that code tends to be more easily understandable to even junior developers and therefore is less prone to bugs being introduced because developer made the wrong assumptions on what the code was doing. Code that is too clever for its own good is where bugs tend to occur.
[+] [-] stonemetal12|4 years ago|reply
For some(especially novices) that means plodding, low abstraction code, so that all the details are visible. This makes for longer code. Others see high abstraction code as the cleaner simpler code because the abstractions hide what they see as irrelevant details, which makes for terse code.
“the less, the better”
“the more, the better”
Tautologically both are incorrect when pursued farther than is prudent, and "the right amount, the better". Unfortunately no one really agrees on what "the right amount" is or we wouldn't have to discus different definitions and strategies to reach "the right amount".
[+] [-] drewcoo|4 years ago|reply
When people first start coding they're trying to get machines to do things. They have to learn the techniques of making code for other humans. To them it's making things verbose and adding tons of comments because that's better.
Meanwhile, they're usually learning to plan for future code needs and make their code flexible.
But part of learning to use those techniques is overuse. So that means code gets gold-plated, baroque, byzantine, and needs a novella of comments to explain its magnificence to future developers so that they use it right. Time to trim it back. Less is more.
I think that's what the author meant.
[+] [-] galangalalgol|4 years ago|reply
[+] [-] ritchiea|4 years ago|reply
[+] [-] jayd16|4 years ago|reply
That is to say, novices can tend to pile onto a solution with hacks and special cases instead of examining why their abstraction requires so much special casing.
I think the code golf you're talking about is a different (but not exclusive) thing.
[+] [-] genezeta|4 years ago|reply
I would agree with that. But then again, it isn't entirely incompatible with the cited quote. That is, at different times in their careers, developers may tend to do different things.
In any case, I think I understand the original quote as something I have indeed seen somewhat frequently in large projects. It seems somewhat common, from my experience at least, that people -particularly "not-so-good developers"- involved in large projects tend to assert how large/important the project in fact is, by mentioning LOCs. "This is a very large project... It's about 5.5MLOCs or so. It will have grown a bit since we last counted."
[+] [-] bena|4 years ago|reply
Both incredibly dense and incredibly verbose code can become maintenance headaches. You want it short enough that it can be contained in your head, but long enough that the steps are obvious.
I liken it to the scene in Return of the Jedi where Han is instructing Chewie to fly close, but not too close.
[+] [-] grp000|4 years ago|reply
[+] [-] ChrisRR|4 years ago|reply
But every day was a game of code golf to him. His code was absolutely illegible
[+] [-] kbenson|4 years ago|reply
I think it's both. There's a sense of accomplishment that goes along with both accomplishing some small task with minimal code, and also for having written a somewhat large chunk of code for a project. Both have their place, as succinctness has it's place, and it's natural to look back and feel proud of a lot of work. It's just when they aren't tempered by the experience to ask whether that terseness came at a cost that wasn't worth it or whether that project is much larger than it needs to be for the task accomplished that it ends up being detrimental.
[+] [-] AceJohnny2|4 years ago|reply
I discovered IRC as a teenager in the 90s, and soon learned SMS-speak for rapid messaging. I was proud of how quickly I could write if I just wrote "u r" instead of "you are"... This was cool! In chatroom arguments, being able to belt out more sentences faster was better!
But as my typing improved, I realized the above was a childish optimization. Real skill was able to write out correctly-spelled sentences just as fast. I then saw the SMS-speak as immature shortcuts.
This realization carried over into code: good code is the clear, adequately verbose (but appropriately concise) kind. Code that tries to be overly-clever (of the "code golf" kind), was to be viewed with suspicion.
[+] [-] mch82|4 years ago|reply
https://rafaelquintanilha.com/how-to-become-a-bad-developer/...
The author lists the habits of *bad* developers as: (1) Never assume there is a bug in your code, (2) Write code without reasoning, (3) Lack assertiveness, (4) Take pleasure in writing more code, (5) Write for machines, not humans.
So the author advocates for less code, but written to be used and maintained by other people.
[+] [-] BitwiseFool|4 years ago|reply
[+] [-] 908B64B197|4 years ago|reply
Depends on the culture. A lot of offshored programmers will report their "performance" as number of lines written. With the expected results...
[+] [-] systemvoltage|4 years ago|reply
Could mean:
1) As you said, terse clever code and agree 100%.
2) Or avoid writing factories that produce factories, abstractions upon abstractions that never get the payoff since the abstraction only gets used for a single (or a handful) of cases ever. When you write abstractions, make sure that in next 10-20 years its going to get its money's worth by taking advantage of it. There are always some exceptions but most of the time I've seen code that has no defense for all the bloat.
3) The best code is the code that you don't write. In this case "the less, the better" indeed.
So I can see multiple meanings of "less, the better". Also, my experience matches the author - new developers are mostly proud of number of lines than cleverness.
[+] [-] corentin88|4 years ago|reply
[+] [-] rafaquintanilha|4 years ago|reply
Maybe I conveyed the wrong meaning on this sentence. I don't think that less code is better. I believe that the more code you have, the more potentially breaking parts you get. However, the right amount of code is a function of your deadline, team, goals, budget and whatnot.
In any case, it's nice to have principles as a beacon during your development, so you don't get lazy and fool yourself. But by no means they are written in stone and every attempt to summarize an absolute truth will be shallow.
[+] [-] jt2190|4 years ago|reply
This is one piece of developer lore that’s actually backed by some research. [1] Like it or not, there is a correlation between lines of code and bug count.
[1] I’ll link to this research when I have a little more time. Edit: Here's a great resource on this: https://www.hillelwayne.com/talks/what-we-know-we-dont-know/
[+] [-] fifticon|4 years ago|reply
[+] [-] toomuchredbull|4 years ago|reply
[+] [-] teucris|4 years ago|reply
Inherently, more code means more chances to explain what it’s doing to other humans, so shouldn’t more code be better?
Obviously not, so I take these two principles in tandem as “write as much code as is needed to accomplish the task effectively and explain how it works, but no more than that.”
Squishy, but I think this article as a whole does a decent job of addressing your concerns.
[+] [-] marcus_holmes|4 years ago|reply
Novice developers are frequently proud of the complexity of their code. Experienced developers write simple, easily understood, code.
[+] [-] dgb23|4 years ago|reply
The more general approach would be to write code with coworkers/audience in mind.
In some environments or projects it might be more effective to write in a way that is harder to grok (requires more work to understand) but is ultimately more tailored to a specific outcome, may that be performance, extensibility, security or what ever.
[+] [-] mcguire|4 years ago|reply
[+] [-] h1fra|4 years ago|reply
In my short career, the worst code was always the one made by the overly experienced CTO that insist on doing everything in a one liner.
[+] [-] joshwcomeau|4 years ago|reply
As I’ve gotten more experienced, my code has gotten less fancy and more verbose. A single terse expression is broken out into 3 or 4 statements, defining variables that capture and name fragments.
But yeah, otherwise really enjoyed the article!
[+] [-] k__|4 years ago|reply
Often even sacrificing everything to that tersness.
[+] [-] slumdev|4 years ago|reply
I've never seen a senior write nested ternary expressions with side effects...
[+] [-] austincheney|4 years ago|reply
* any original code is NIH
* vetted by the community
* original code can fail
[+] [-] johnalbertearle|4 years ago|reply
[+] [-] TrackerFF|4 years ago|reply
I've seen very talented developers fall prey for that one. They seem to fit the pattern of your typical "hacker" type that grew up spending all their youth on coding, and thus binding a lot of their identity and self-worth to their coding abilities.
They blaze through college, being extremely competitive among their peers, and are often among the "go-to" students in class, which only boosts their ego even further.
Then they join the workforce, and find themselves having to work with other people - and they hate it. Any hint of criticism is taken deeply personal, like a sledgehammer to their self-worth. Tips and tricks from others are equally bad - who are they to teach you anything? After all, you've been banging out code and reading books since you were 9.
Code review is like walking on eggshells for the others - they know you'll roll your eyes, chuckle and snort, and just shoot down any incoming comment.
If only you didn't have to work with all these morons around you - the very people that are slowing you down. Move fast and break things, isn't that the motto?
[+] [-] sdevonoes|4 years ago|reply
I've seen people reading about CQRS, Clean Code, Hexagonal Architecture, Event Bus, all these "good practices" published by celebrities... and after some time these people believe "they are right" because they know these patterns and because they apply them every time code needs to be written. It's difficult to reason with them; the conversation usually goes this way:
- Joe: We should use Hexagonal Architecture in our new system because Alistair Cockburn knows what's best
- Me: I think we don't need it? Past experience in other projects of ours says we can handle this new system without HA
- Joe: I don't think you know better than Alistair Cockburn, so let's stick with HA
[+] [-] PragmaticPulp|4 years ago|reply
Very common trap. Most of us grew up with a natural enjoyment of programming, so it’s easy to lose sight of the fact that our job as engineers isn’t to produce more and more code. Our job is to deliver results, not lines of code.
This often manifests as developers or entire teams that can’t stop rewriting, refactoring, and rearchitecting code that is already good enough. They might want to rewrite their otherwise working service in Rust because Node.js is no longer popular, or rework the stable React app to use hooks, or fork and maintain a popular open-source project because they think they can improve it. They prefer to write generalized solutions or frameworks from the start instead of writing a specific one-off solution to get the job done. Or maybe they just have perfectionist tendencies and struggle to submit that PR until they make just one more improvement.
This isn’t unique to developers, of course. My last company had a major problem with UI/UX designers who could never finalize their designs. We lost countless months to endless iterations and tweaks. Part of the problem lies with management, of course, if they’re not enforcing actual project deadlines and end times.
[+] [-] okareaman|4 years ago|reply
My misfortune was being assigned to take over one of the projects he threw together. My god, what a mess. He literally had 10 to 20 boolean flags in every pages long functions so that it was extremely difficult to tell what path the code would take under what circumstances. I got fired because I couldn't understand the code enough to enhance it. I was judged inadequate.
A couple of years later I had lunch with the developer who took my place. She told me what code she was working on. When I casually said "Oh, that spaghetti code is still used?" she let out a big sigh. She thought the problem was with her and finally someone had come along to call out the crappy code this "rockstar" was foisting on everyone.
[+] [-] goda90|4 years ago|reply
My manager showed me where I fall on the company-wide distribution of quality(based on issues attributed to my code), and quantity(based on logical lines of code committed). I was near the top for quality, and near the median for quantity. My project had been fairly complex, involving the joining of two already complex systems that handle a wide range of configurations and had their own fair share of bugs that I had to figure out. I held my tongue when they said that I should work on increasing my output.
[+] [-] rafaquintanilha|4 years ago|reply
I should mention that the "rules" there are completely opinionated and reflect what I understood as the biggest problems I had (and still have) as a software engineer.
Also would like to clarify that "via negativa" is a general principle, but of course won't work all the time. As a matter of fact, I refrain myself from excessive modularization whenever I can. In the end, software development is about delivering the biggest value, in less time, without compromising quality and maintainability (or at least being aware of the costs).
A nice side-effect of this semi-virality is that I get to read a lot of nice additions to the original 5 points. This post is calling for a sequel...
[+] [-] Jtsummers|4 years ago|reply
I had a boss who went with, "Always assume the bug is in our code." Which wasn't too bad, except for the time he wouldn't let us tell the hardware partner they probably had a bug until we could definitively prove that it was their problem and not ours. Took us a few months to produce a reliable test case for the error (consistent failures and not sporadic ones) and shifted the entire project schedule (not just us) right. He just didn't trust us lowly CS types.
[+] [-] OskarS|4 years ago|reply
I agree with the author's reasoning that the number of lines of code you write is meaningless and not something you should hold up with pride, but there is a flipside to that: when you get to a certain amount of experience, code verbosity is usually a good thing.
At some point when learning, many programmers become good enough at thinking in code that they become able to express everything in incredibly terse one-liners. This is when they start using ternary operators everywhere instead of if statements, or very obscure functional map/reduces instead of simple for loops.
Being able to write like this is obviously good, but that doesn't mean you should do it: just because you can cram everything into one line/statement, doesn't mean you should. This gig is not just about writing clever code, it's about writing code that others can read (as well as yourself, six months later) and reason about and debug easily.
Writing understandable code is not always the same as writing more verbose code, but the two are certainly correlated.
[+] [-] 29athrowaway|4 years ago|reply
- Stop caring about understanding what you are doing.
- Stop caring about the quality of your deliverables.
- Stop caring about understanding how things work.
- Stop caring about finding better ways of doing things.
- Stop caring about learning.
- Stop caring about what you have learned and how you can use it.
There are many factors that will make tempt you stop caring, but you should resist them and persevere. One of such factors is: mediocre jobs, mediocre leadership.
If you stop caring, you'll become unemployable in a few years, and any advantage you had over younger developers will go away.
[+] [-] Osiris|4 years ago|reply
I can't tell you how many bugs I've fixed because programmers write code that only works if everything goes exactly the way they expect.
[+] [-] fighterpilot|4 years ago|reply
Callbacks everywhere. Confusing use of compositions - A is in B but also B is in A, making it impossible to reason about.
[+] [-] tuyguntn|4 years ago|reply
nowadays, 2 biggest advise I get from articles and books are: (1) make code as readable as possible (2) write code so it is easy to remove the code and re-write. basically advising me to write such methods: StoreUserDataAndFetchDetailsFromOauthProvider, instead of some fancy flows
world is moving very fast and time spent on making code modular with design patterns seems not worth it (I am spending my last 6-8 years in startups).
most of my code is verbose and doesn't contain design patterns, am I that bad developer?
[+] [-] DoctorNick|4 years ago|reply
[+] [-] Tade0|4 years ago|reply
I lost count how many times I had to fight over doing actual work and coming clean on how much is really done versus making the result only appear finished and knowingly merging buggy code.
Stakeholders put pressure because of course they do. That doesn't mean lying to them is a sound tactic. It's much better to negotiate a reduction of scope than pretend you've delivered only to later have them, or worse - the users - discover the truth.
[+] [-] Exuma|4 years ago|reply
Step 2: Don't ask questions, don't know how to communicate
Step 3: Take ideally 1 day or more to respond to clients
[+] [-] sjatkins|4 years ago|reply
[+] [-] mywittyname|4 years ago|reply
I could see this being a "good developer" trait too. For example, writing programs that are designed to be easily consumed by other programs. Humans might like a nicely formatted HTML page, but machines like plain text output.
[+] [-] tarkin2|4 years ago|reply
I would prefer a developer who can work with a large amount of code. I would prefer, even more, a developer who can write the same thing with less code. Generally speaking, a developer doesn't gain the ability to the do the latter without first doing the former.
And there's an annoying phase in the middle where "less code" is condensed code.
[+] [-] flippinburgers|4 years ago|reply
I cannot stand that approach. The real tell is that none of them have ever used a raw html element in any of the code they have written. It is more or less custom components on top of something like material-ui or bust! Yikes.