You feel smart writing clever code, and you may even justify it by saying it's less code. However, code should be explicit and thus be understandable by everyone. Even if that means writing slightly more code.
Good idea. Clever code typically comes along with learning intricacies of a language, so in JavaScript it's totally valid to write an if condition like this:
isDataValid&&submitData();
This totally works, but with a few more characters, we can make the intention more explicit and clear:
if(isDataValid)submitData();
Here's another example. Let's say we need to set a timeout of 5 seconds. We can use clever code here too:
setTimeout(()=>{// run this after 5 seconds},5e3);
Woah, what is that 5e3? It's exponential notation, and while it looks cool and is less characters, is totally unnecessary. Just use a regular number:
setTimeout(()=>{// run this after 5 seconds},5000);
Even better would be to extract to a variable like FIVE_SECONDS so that you don't have to do any conversion between milliseconds to seconds.
The first example is actually OK in my opinion, short-circuit is a handy feature most of the times, for things such as JSX you don't really have another succinct alternative.
Take a look at this one which I found in an old codebase, back in the days:
There're a lot of obscure ways to take advantage of JS's type cohesion, but you'll quickly lose track of what this kind of code means. Further, it might even have surprising, unexpected behaviors. There's nothing wrong doing:
Great point! I would add that "clever code" is often is just saving symbols, while sacrificing readability, expressiveness and distorting meaning.
In the example with "&&" we rely on the fact that in JS code on the right part of logical AND won't be executed. So it is sort of a "hack". And I think that majority of such "clever code" examples are in fact hacks.
It's important to understand that when we write code - we have different sorts of stakeholders. And one of important categories of those are developers themselves!
It is important that code not only performs some useful action, but is also convenient to work with and is understandable.
Regarding JSX though, it's a totally valid use case for using && and ternary operators since you're conditionally rendering pieces of UI this way. From a declarative perspective, it's fairly clean.
Love the Number(id) example too. Not only does it handle null values, but you can more clearly understand that you're converting to a number.
I disagree that 5e3 is clever. Exponential notation is something that every coder should learn. It appears in a lot of places and is much clearer that expanded numbers.
I did a lot of work with nanoseconds much, and I would have to see 1500000000 in the code versus 1.5e9. With larger numbers the exponential format is preferred.
Of course, I'd also like a language that allows separators (I did in Leaf, like 5_000.
Note though, on the second I think any api that accepts something other than seconds for duration by default is broken. Seconds is the natural time, milliseconds is unusual. Thus a conversion function would be nice to see there.
It's clever in that scenario because seeing the exponential notation for most people will require more brain processing power than simply seeing 5000 milliseconds or 5 seconds.
It also really just depends on what you're building. Web development rarely requires you to use exponential notation, and so declaring it as "something that every coder should learn" is not an absolute that I can get behind.
I was going to mention that. When using something like Codewars, it's really easy to see clever solutions by others and then possibly get into the habit of always trying to be clever too.
It is fun to try to be clever on stuff like that, but it's almost never necessary—at least not to that degree.
I've been doing that a lot in CodeWars. Putting the entire code in a single return statement. I'm talking about converting a string to an array, running map and reduce on it, then converting it back to a string in a single return statement.
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? -- Brian Kernighan
Unfortunately, there are many frameworks today that suffer from this mentality.
An excellent example would be a framework like Laravel. Certain aspects of it are really nice. Eloquent ORM, for instance. But other aspects create levels of abstraction that make the code difficult to understand. Are some of the ideas clever? Yes. But they make maintaining the code confusing.
Software Developer who works mostly on Web stuff. I like JS, but I also like other things. I also do photography, and look at sneakers online that I will never be able to buy.
I've had to struggle with this myself! I've had the urge to grab an existing, working piece of code and rewrote it to be shorter and sometimes less understandable. It's for sure something I have become more aware of and that I have to think about when refactoring code.
I totally agree. Writing code is an art and, like painting, there are many styles.
When painting something abstract, the artist surely knows not all viewers will understand the painting. When writing code, you should strive to paint photorealism, where the code can't be misinterpreted.
There are times where obscure code can't be avoided, though. If it's convention in a framework you're using, for instance, then it's okay because later coders should understand the convention. Otherwise, it's a perfect opportunity for an explanatory comment. This also helps you not try to be "clever" because writing the comment nullifies any handful of keystrokes saved by being so.
An insecure justification of why you don’t know something (off the top of your head). Some folks lose this habit over time, others only get worse.
It’s okay not to know something, you don’t have to explain the specific reason why you don’t happen to know that. Sometimes you just won’t know a thing and you don’t need to nervously elaborate on why you don’t know.
😮 I’ve been senior or lead/principal for about a decade and sometimes I think I’m the only one who will say “I don’t know. I’ll do some research and get back to you.” I’m happy there are others who will do the same. I’m an engineer Jim, not an encyclopedia.
"I don't know everything, if I was that smart, you couldn't afford me. ;-)
However, let me look into it and I'll get back to you. "
... and then get back to them.
I'm a big proponent of "I don't know" being a safe phrase on my team. I would much rather hear "IDK" than hear (and see) someone grasping for an answer.
That being said, it helps nubies to empathize. Let them know this is very common. When new devs start working, I think they are used to being the smartest person in the room their whole lives. Suddenly, everyone is just like that! It's a shocker for them. Eventually the shock wears off and they become more comfortable being vulnerable.
Wish I had a boatload of humility to pass around. We could save a lot of time getting through this issue!
This! It's so frustrating especially when they are a little bit out of touch on how some things work, due to them taking more responsibility on a managerial role and so have less time to keep up to date with tech at the coding level. But they'll still want to walk over you and dismiss your opinion because you're more junior compared to them 🙄
My new job involves dealing with a 30-year-old Oracle Team. They still code in obsolete ways, that even Oracle advise against. "But it works still!" ? angery
This! Also, assuming you have more years of experience. So many people assume I've been doing this for a couple of years, when in reality, it's been 10+ years.
There are absolutely brilliant women in STEM and they deserve equity.
There is a problem though in the calculus for placing more women in positions in tech related fields. The men are the people who need to change, not the women. It’s not that women need to be interested in STEM. Plenty of them are. The men need to be prepared to treat the women equally. That isn’t the case in so many places I’ve worked.
Being insulted if someone tries to explain to them something they already know. It enforces the (bad) idea that everyone should know everything, and shuts down devs who preface a conversation with some required information just in case the other party isn't at the same level or might think they're talking about something else.
Juniors should avoid adopting the gatekeeping behavior a lot of seniors adopt. No developer should think themself superior just because they work for a large tech company, write in a certain language, use a particular framework, went to a certain school, or any of another umpteen things.
Related to this are dogmatic behaviors like one line absolutist comments on code reviews without justification (like “Never return null”) or believing in one right tool for a given job (“I’d only use Spring to write web services and anyone who does something else is an idiot”).
Becoming complacent with your job or knowledge. I've seen many senior developers that get comfortable maintaining some system they built. Software development and technologies are constantly evolving, don't get left behind!
With that said, that doesn't mean you should learn every shiny technology that comes out. But it does mean that you should aim to learn the fundamentals and pick up the latest tools at least every couple of years to stay relevant.
Saying "it's simple, I don't know what you're missing" to people when explaining something.
Just saying it's simple most of time when explaining things can make someone feel dumb if they don't get it. Adding the "I don't know what you're missing" part just makes them feel worse. Trying to sound "elite" isn't helping anyone and is not needed.
Not being offended when someone comments on a PR, files a bug report, asks you to refactor something you wrote, etc.
It's not personal, and they're not saying you're a bad developer.
Let me say that again (in large part to myself, because I was really bad about this): it's not personal.
In time you'll learn that you're not a perfect developer, and all these things are actually trying to help you get better at your craft. They just want to help you improve the product, the codebase, and yourself.
I think many engineer's passion for programming and creating tend to decline as they spend time in industry. They may look back at their old hobby projects and remember the nights they stayed up fueled by their desire to make something with a sort of nostalgia. They remember these as the good times when they really cared and were excited about what they were doing.
Although I'm not a senior engineer by any means, I think it's important to allow your passions to change along with you. I want to remember what I love about programming and engineering, find new things to love, and let some things I love go. That way I can allow myself to find the things that make every single day of my career enjoyable.
To add to this, its okay if your passion isn't coding. Trying to pretend it is and burning out isnt good for you, your employer or your long term health.
Having strong opinions, weakly held.
It's a fundamental in having a constructive discussion, technical or otherwise. It's also an excellent way to "absorb" knowledge from other developers.
The strong opinions aspect means that you know and put across a compelling argument for the topic of conversation. This doesn't mean that you must be a subject matter expert, only that you can advocate for the topic.
The key is only weakly holding it, and this is something I have been guilty of in the past.
Weakly holding the opinion means you are still open to have your opinion changed based on the discussion. It doesn't equate yourself to "losing" the argument, it just means that you have considered the merits of both arguments and now see the benefits of the apposing opinion.
Not taking this approach can lead to something that Eric Dietrich has blogged about; the expert beginner.
There's also many articles on this principle out there, but I would recommend reading the post by Jeff Atwood.
Assuming that people know the systems architecture, and underlying infrastructure. It is very important to get a high level overview of how a system works, even if you don't fully understand how it all works. At least it will help you in understanding the flow of data.
Suggesting before listening. It's easy to do this when you have a lot of experience to draw from, but it makes less sense to people since they don't have the same experience. Take a step back, listen, choose your words carefully so that the point is delivered across more effectively.
Try to understand the whole thing before implementing.
When we are junior, most of the times, in order to resolve an issue we look up just for the code, do a kind of copy/paste and continue, because the topic seems pretty hard at first glance, when we are senior we believe that it would be easy task and we don't investigate, read properly, etc and start implementing things, some hours later, we ended up deleting the code because it wouldn't work and start trying to understand the topic from scratch.
My name is Matteo and I'm a cloud solution architect and tech enthusiast. In my spare time, I work on open source software as much as I can. I simply enjoy writing software that is actually useful.
For my money, a knee-jerk reaction of "we can't do that" is something to avoid.
I've worked with many brilliant devs. Once they get a certain level of knowledge and experience, often there's a knee-jerk to a client or stakeholder request that it's not easily possible in whatever platform or code base we're working in. I'd say 75%-90% of the time after that, they usually come back on their own and say "oh, we could do it one of these ways with these trade-offs." But that initial knee-jerk can be disheartening.
I'd like to see more devs say "I'm not sure" before saying "no." A lot of seniors think saying "I don't know" is a bad thing. It's only bad if it's not followed by "But I'll find out!"
Trying to solve all issues that are identified in the software themselves. Most times we end up piling up fixes we know how to solve, just because we think we’re the ones that should be solving them.
Let your team deal with them, teach them, and let them solve those issues their way.
Data wrangler, software engineer, systems programmer, cyclist. Unix (mostly Solaris) for aeons. I talk C, Python, SQL, Performance, Java, Kafka and Makefiles.
Location
Brisbane, Australia
Education
BA (Mathematics, Modern History), University of Queensland
Data wrangler, software engineer, systems programmer, cyclist. Unix (mostly Solaris) for aeons. I talk C, Python, SQL, Performance, Java, Kafka and Makefiles.
Location
Brisbane, Australia
Education
BA (Mathematics, Modern History), University of Queensland
Sigh ... I was sure that when I responded to Ben's post this morning it was about habits that juniors should adopt, rather than should not.
The worst habit I've come across from senior engineers has been the tendency (based on their experience in the past) to shut down a request to consider either a new feature or a new way of doing something - and do so without explaining why.
How are more junior engineers (let alone management!) supposed to understand the problem better if you do not explain things (carefully and without rancour or attitude) to them?
I’m thinking here of people like Ryan Dahl, the creator of NodeJS, who built a product used by hundreds of Fortune 500 companies and millions of developers world-wide, but made only a fraction of the profits that the VCs behind Nodejitsu made.
This is not to slight investors – I’m an investor myself (on a vastly smaller scale). Just to warn my future senior developer self to be on the lookout for monetisation opportunities, and not let them slip away into the hands of those who are more aware of the financial and business side of things.
What a co-worker of mine refers to as "licking the cookie", which is to say getting attached to, or feeling ownership of, a code base. This is especially true in highly collaborative environments. I've seen this in two ways, the first is folks getting frustrated when a project dies on the vine, or is sunsetted. Priorities change, technologies shift. This is part of business. The second is harder. When someone rewrites parts of or takes over anothers code base. This can cause feels, and while understandable, again it happens.
Conversely (and ironically perhaps) is, taking over or rewriting anothers codebase with out direction to or having a conversation about doing so. Too many times I've seen (and done it myself) a more senior level engineer come in and bowl over a more junior engineers work. Even when necessary, there is a lost teaching moment here and it's bad form.
A *very* seasoned software engineer, I wrote my first basic game, a lunar landing game, in Basic in 1969. Currently I am doing web development in Ruby on Rails, JavaScript, Elm.
A *very* seasoned software engineer, I wrote my first basic game, a lunar landing game, in Basic in 1969. Currently I am doing web development in Ruby on Rails, JavaScript, Elm.
Avoiding clever code.
You feel smart writing clever code, and you may even justify it by saying it's less code. However, code should be explicit and thus be understandable by everyone. Even if that means writing slightly more code.
For juniors who might be reading, can you give an example of clever code and a good alternative?
Good idea. Clever code typically comes along with learning intricacies of a language, so in JavaScript it's totally valid to write an if condition like this:
This totally works, but with a few more characters, we can make the intention more explicit and clear:
Here's another example. Let's say we need to set a timeout of 5 seconds. We can use clever code here too:
Woah, what is that
5e3? It's exponential notation, and while it looks cool and is less characters, is totally unnecessary. Just use a regular number:Even better would be to extract to a variable like
FIVE_SECONDSso that you don't have to do any conversion between milliseconds to seconds.The first example is actually OK in my opinion, short-circuit is a handy feature most of the times, for things such as JSX you don't really have another succinct alternative.
Take a look at this one which I found in an old codebase, back in the days:
There're a lot of obscure ways to take advantage of JS's type cohesion, but you'll quickly lose track of what this kind of code means. Further, it might even have surprising, unexpected behaviors. There's nothing wrong doing:
Great point! I would add that "clever code" is often is just saving symbols, while sacrificing readability, expressiveness and distorting meaning.
In the example with "&&" we rely on the fact that in JS code on the right part of logical AND won't be executed. So it is sort of a "hack". And I think that majority of such "clever code" examples are in fact hacks.
It's important to understand that when we write code - we have different sorts of stakeholders. And one of important categories of those are developers themselves!
It is important that code not only performs some useful action, but is also convenient to work with and is understandable.
Maksim nailed it.
Regarding JSX though, it's a totally valid use case for using
&&and ternary operators since you're conditionally rendering pieces of UI this way. From a declarative perspective, it's fairly clean.Love the
Number(id)example too. Not only does it handle null values, but you can more clearly understand that you're converting to a number.I disagree that
5e3is clever. Exponential notation is something that every coder should learn. It appears in a lot of places and is much clearer that expanded numbers.I did a lot of work with nanoseconds much, and I would have to see
1500000000in the code versus1.5e9. With larger numbers the exponential format is preferred.Of course, I'd also like a language that allows separators (I did in Leaf, like
5_000.Note though, on the second I think any api that accepts something other than seconds for duration by default is broken. Seconds is the natural time, milliseconds is unusual. Thus a conversion function would be nice to see there.
It's clever in that scenario because seeing the exponential notation for most people will require more brain processing power than simply seeing 5000 milliseconds or 5 seconds.
It also really just depends on what you're building. Web development rarely requires you to use exponential notation, and so declaring it as "something that every coder should learn" is not an absolute that I can get behind.
I agree.
But writing clever code for fun can be pretty fun.
As long as other people aren't ever going to be burdened by reading your code-golfed 5 character insertion sort, I think it's fair game :)
I was going to mention that. When using something like Codewars, it's really easy to see clever solutions by others and then possibly get into the habit of always trying to be clever too.
It is fun to try to be clever on stuff like that, but it's almost never necessary—at least not to that degree.
I've been doing that a lot in CodeWars. Putting the entire code in a single return statement. I'm talking about converting a string to an array, running map and reduce on it, then converting it back to a string in a single return statement.
Yea exactly what I'm talking about :) It's fun right!
Unfortunately, there are many frameworks today that suffer from this mentality.
An excellent example would be a framework like Laravel. Certain aspects of it are really nice. Eloquent ORM, for instance. But other aspects create levels of abstraction that make the code difficult to understand. Are some of the ideas clever? Yes. But they make maintaining the code confusing.
I've had to struggle with this myself! I've had the urge to grab an existing, working piece of code and rewrote it to be shorter and sometimes less understandable. It's for sure something I have become more aware of and that I have to think about when refactoring code.
I totally agree. Writing code is an art and, like painting, there are many styles.
When painting something abstract, the artist surely knows not all viewers will understand the painting. When writing code, you should strive to paint photorealism, where the code can't be misinterpreted.
There are times where obscure code can't be avoided, though. If it's convention in a framework you're using, for instance, then it's okay because later coders should understand the convention. Otherwise, it's a perfect opportunity for an explanatory comment. This also helps you not try to be "clever" because writing the comment nullifies any handful of keystrokes saved by being so.
That's a good point. If you must write clever code, then at least provide a comment explaining why that code is there.
This, and your examples, were very helpful. Thank you!
One thing that comes to mind for me:
An insecure justification of why you don’t know something (off the top of your head). Some folks lose this habit over time, others only get worse.
It’s okay not to know something, you don’t have to explain the specific reason why you don’t happen to know that. Sometimes you just won’t know a thing and you don’t need to nervously elaborate on why you don’t know.
😮 I’ve been senior or lead/principal for about a decade and sometimes I think I’m the only one who will say “I don’t know. I’ll do some research and get back to you.” I’m happy there are others who will do the same. I’m an engineer Jim, not an encyclopedia.
"I don't know everything, if I was that smart, you couldn't afford me. ;-)
However, let me look into it and I'll get back to you. "
... and then get back to them.
I'm a big proponent of "I don't know" being a safe phrase on my team. I would much rather hear "IDK" than hear (and see) someone grasping for an answer.
That being said, it helps nubies to empathize. Let them know this is very common. When new devs start working, I think they are used to being the smartest person in the room their whole lives. Suddenly, everyone is just like that! It's a shocker for them. Eventually the shock wears off and they become more comfortable being vulnerable.
Wish I had a boatload of humility to pass around. We could save a lot of time getting through this issue!
Thinking you're right because of many years of experience.
This! It's so frustrating especially when they are a little bit out of touch on how some things work, due to them taking more responsibility on a managerial role and so have less time to keep up to date with tech at the coding level. But they'll still want to walk over you and dismiss your opinion because you're more junior compared to them 🙄
My new job involves dealing with a 30-year-old Oracle Team. They still code in obsolete ways, that even Oracle advise against. "But it works still!" ? angery
This! Also, assuming you have more years of experience. So many people assume I've been doing this for a couple of years, when in reality, it's been 10+ years.
Sexism
☝️ The most important of them all.
There are absolutely brilliant women in STEM and they deserve equity.
There is a problem though in the calculus for placing more women in positions in tech related fields. The men are the people who need to change, not the women. It’s not that women need to be interested in STEM. Plenty of them are. The men need to be prepared to treat the women equally. That isn’t the case in so many places I’ve worked.
Absolutely.
Being insulted if someone tries to explain to them something they already know. It enforces the (bad) idea that everyone should know everything, and shuts down devs who preface a conversation with some required information just in case the other party isn't at the same level or might think they're talking about something else.
Checking emails after hours. I used to be a fiend for it, but I've come to realise my time is worth more.
Juniors should avoid adopting the gatekeeping behavior a lot of seniors adopt. No developer should think themself superior just because they work for a large tech company, write in a certain language, use a particular framework, went to a certain school, or any of another umpteen things.
Related to this are dogmatic behaviors like one line absolutist comments on code reviews without justification (like “Never return null”) or believing in one right tool for a given job (“I’d only use Spring to write web services and anyone who does something else is an idiot”).
Becoming complacent with your job or knowledge. I've seen many senior developers that get comfortable maintaining some system they built. Software development and technologies are constantly evolving, don't get left behind!
With that said, that doesn't mean you should learn every shiny technology that comes out. But it does mean that you should aim to learn the fundamentals and pick up the latest tools at least every couple of years to stay relevant.
Saying "it's simple, I don't know what you're missing" to people when explaining something.
Just saying it's simple most of time when explaining things can make someone feel dumb if they don't get it. Adding the "I don't know what you're missing" part just makes them feel worse. Trying to sound "elite" isn't helping anyone and is not needed.
Not being offended when someone comments on a PR, files a bug report, asks you to refactor something you wrote, etc.
It's not personal, and they're not saying you're a bad developer.
Let me say that again (in large part to myself, because I was really bad about this): it's not personal.
In time you'll learn that you're not a perfect developer, and all these things are actually trying to help you get better at your craft. They just want to help you improve the product, the codebase, and yourself.
I think many engineer's passion for programming and creating tend to decline as they spend time in industry. They may look back at their old hobby projects and remember the nights they stayed up fueled by their desire to make something with a sort of nostalgia. They remember these as the good times when they really cared and were excited about what they were doing.
Although I'm not a senior engineer by any means, I think it's important to allow your passions to change along with you. I want to remember what I love about programming and engineering, find new things to love, and let some things I love go. That way I can allow myself to find the things that make every single day of my career enjoyable.
To add to this, its okay if your passion isn't coding. Trying to pretend it is and burning out isnt good for you, your employer or your long term health.
Having strong opinions, weakly held.
It's a fundamental in having a constructive discussion, technical or otherwise. It's also an excellent way to "absorb" knowledge from other developers.
The strong opinions aspect means that you know and put across a compelling argument for the topic of conversation. This doesn't mean that you must be a subject matter expert, only that you can advocate for the topic.
The key is only weakly holding it, and this is something I have been guilty of in the past.
Weakly holding the opinion means you are still open to have your opinion changed based on the discussion. It doesn't equate yourself to "losing" the argument, it just means that you have considered the merits of both arguments and now see the benefits of the apposing opinion.
Not taking this approach can lead to something that Eric Dietrich has blogged about; the expert beginner.
There's also many articles on this principle out there, but I would recommend reading the post by Jeff Atwood.
Assuming that people know the systems architecture, and underlying infrastructure. It is very important to get a high level overview of how a system works, even if you don't fully understand how it all works. At least it will help you in understanding the flow of data.
Suggesting before listening. It's easy to do this when you have a lot of experience to draw from, but it makes less sense to people since they don't have the same experience. Take a step back, listen, choose your words carefully so that the point is delivered across more effectively.
Try to understand the whole thing before implementing.
When we are junior, most of the times, in order to resolve an issue we look up just for the code, do a kind of copy/paste and continue, because the topic seems pretty hard at first glance, when we are senior we believe that it would be easy task and we don't investigate, read properly, etc and start implementing things, some hours later, we ended up deleting the code because it wouldn't work and start trying to understand the topic from scratch.
Thinking that known solutions to known problems are the best, if not the only, solutions.
Computer science evolves every day, and new solutions might be more efficient, or simpler, or just worth checking out.
For my money, a knee-jerk reaction of "we can't do that" is something to avoid.
I've worked with many brilliant devs. Once they get a certain level of knowledge and experience, often there's a knee-jerk to a client or stakeholder request that it's not easily possible in whatever platform or code base we're working in. I'd say 75%-90% of the time after that, they usually come back on their own and say "oh, we could do it one of these ways with these trade-offs." But that initial knee-jerk can be disheartening.
I'd like to see more devs say "I'm not sure" before saying "no." A lot of seniors think saying "I don't know" is a bad thing. It's only bad if it's not followed by "But I'll find out!"
Trying to solve all issues that are identified in the software themselves. Most times we end up piling up fixes we know how to solve, just because we think we’re the ones that should be solving them.
Let your team deal with them, teach them, and let them solve those issues their way.
A few things:
Sigh ... I was sure that when I responded to Ben's post this morning it was about habits that juniors should adopt, rather than should not.
The worst habit I've come across from senior engineers has been the tendency (based on their experience in the past) to shut down a request to consider either a new feature or a new way of doing something - and do so without explaining why.
How are more junior engineers (let alone management!) supposed to understand the problem better if you do not explain things (carefully and without rancour or attitude) to them?
Undervaluing and under-monetising their work!
I’m thinking here of people like Ryan Dahl, the creator of NodeJS, who built a product used by hundreds of Fortune 500 companies and millions of developers world-wide, but made only a fraction of the profits that the VCs behind Nodejitsu made.
This is not to slight investors – I’m an investor myself (on a vastly smaller scale). Just to warn my future senior developer self to be on the lookout for monetisation opportunities, and not let them slip away into the hands of those who are more aware of the financial and business side of things.
What a co-worker of mine refers to as "licking the cookie", which is to say getting attached to, or feeling ownership of, a code base. This is especially true in highly collaborative environments. I've seen this in two ways, the first is folks getting frustrated when a project dies on the vine, or is sunsetted. Priorities change, technologies shift. This is part of business. The second is harder. When someone rewrites parts of or takes over anothers code base. This can cause feels, and while understandable, again it happens.
Conversely (and ironically perhaps) is, taking over or rewriting anothers codebase with out direction to or having a conversation about doing so. Too many times I've seen (and done it myself) a more senior level engineer come in and bowl over a more junior engineers work. Even when necessary, there is a lost teaching moment here and it's bad form.
Cynicism >.>
Needlessly using anything from the System.Linq namespace when a
forloop would work fine. Those extension methods are hard to read and debug.Bad posture. If you don't sit up straight you will regret it.
we have been ground down by the trials and tribulations of software dev :D
Arrogance
Forgetting they have survivorship bias