I thunk there's a second "flavor" of arrogance, where a person believes they're the smartest, but not most knowledgeable, in the room. These people will openly admit they can improve and seek training, partly because they believe they're capable of anything. They don't think they're at the top of the mountain, just that their mountain has no peak.
The real problem is they believe "lazy" coworkers will eventually be below them in every subject. They may seek out colleagues' advice some times, but likely will never return because they "get it" now."
They'll act like a "jack and master of all trades." This can be nice in small teams, but usually leads to components nobody (not even the arrogant one) can understand let alone maintain. So experts need to be brought in, anyway.
These people let the quick ascent of "Mount Ignorance" multiple subjects get to their head. No such thing as a Renaissance man anymore.
Arrogance has very little to do with thinking you know a lot, or disagreeing with others, and everything to do with failing to follow social protocol. If you let other people speak, pause long enough that they feel like you are giving their words a fair evaluation, and then don't use words that they must interpret as telling them they are wrong you will not be seen as arrogant. This is true even if you rarely or never agree with anyone.
- let people finish their statement: If you don't let someone finish and you interrupt, they will decide that you are just refusing to hear them out rather than disagreeing. It doesn't matter if you can prove mathematically with extensive sources and footnotes, most of the time they won't be able to accept that you understood their point and showed it to be flawed.
- pause long enough after they speak: Again, if you instantly explain why they are wrong, most of the time other people will not be able to handle this. They will decide you didn't actually consider what they said. It doesn't matter what is actually true, and if you somehow do convince them that you are right they will be doubly resistant since you are making them feel stupid on top of everything else. A huge benefit of this and the previous bullet is that you will often find that at first you misinterpreted what the person was saying, so you were about to disagree for no reason.
- don't force them to admit to themselves that they were wrong: if you let people 'save face' they can just get on board and agree with you. If you force them to grapple with being wrong they will be difficult and will hate your guts. It may seem silly, but replying 'I don't think that will work because ...' is going to be the source of turmoil, when saying 'Interesting. Previously we did something similar to that but we had a problem where ...' is going to win the other person over instantly most of the time. Later they will see that they were wrong, but you didn't rub their nose in it and force them to grapple with it in a social setting where they are going to have to feel shame.
Failure to do these things is just what people mean whenever they say someone is arrogant.
That take might be overly cynical. People who have a jack-of-all-trades skill set might not necessarily build the best components themselves, but might be able to bring some big-picture insight that more specialized developers don't have the awareness for, leading the team in the right direction.
I'm not suggesting you transition into becoming a PM or Architect or anything like that, just saying that developers like you count, too. If you have a decent work ethic, then you and your unique brand of knowledge-seeking have something to bring to the table.
> "usually leads to components nobody can understand let alone maintain"
As you advance up the mountain, you will learn to see complexity simply. When you make this realization, your components will simplify dramatically. You must learn to see simply before you can design simply. It just takes time. There's nothing wrong with this, humility doesn't mean giving up your belief that you're capable of anything.
We were all born without any knowledge. We all learned everything we needed to know to get where we are today. We've put men on the moon. We've sent probes to escape our solar system. We've sent submarines to the bottom of the ocean. Humans have the capability to do anything we put our minds to. You can too. Everything you understand today, you've learned in the short lifespan you've had. Today you will learn more, and tomorrow and the next. Just because you find humility in your place, doesn't mean you're not capable of anything.
I have been concerned about occupying a similar space myself. The great secret that we all do well to remember is that being humble is simply a matter of practicing being humble. In particular, when I treat other team members as experts in what they do, and trust that they'll value me for whatever it is that I do, I become much more efficient, and feel more relaxed too. Yes, there are still times that I notice myself acting vain, but these days a few slow, grounding breaths goes a long way toward resetting me.
In fact, I wonder if the narcissism you speak of might have more to do with insecurity, deep down. In my experience, when I see myself taking a behavior that I consciously am against, the cause tends to be emotional and the solution tends to be to gently, curiously observe those situations and start questioning how I feel. When I love and take care of my emotional world, it becomes way easier to interact in a way I feel is more optimal on the fly.
I just read the article and was like “I don’t think I suffer from these much at all” then read this comment. This is very insightful and also something I just realized that I greatly suffer from. Thanks.
Thank you for your admission. I too am naturally arrogant. People think I'm being weird if I'm not arrogant. I get weird people saying they don't believe me when I'm being humble. Probably because arrogant is who I am as a person. I feel people like me more when I'm being my arrogant self. Oddly, when I was my least arrogant and most humble I exhibited most of the traits in this article.
I was quite sour over the fact that I felt like during the interview process I was lied to about the position and what it would entail. Naturally, I was a bit salty about it and the fact that people were doing things that I would get criticized for. It ultimately hurt my confidence in myself. This made me exhibit most if not all of these traits during my stay at this company. I was trying to make lemons into lemonade. Ultimately I was able help us get on the right path and I was happy with my contributions to the team even if it did ruffle feathers and those people hated me afterwards. I took their criticism and I still try to use it to be a better person to work with.
This take can cause a pretty unproductive worldview. The trouble is, we've all met different people who fall into broad categories like "jack of all trades". A lot of morons will say this sort of thing. Sometimes it's because they think you think they are dumb, so they want to show you that they are good at other stuff so as to keep their ego happy.
However, generalists are a very useful component of a team. They tend to be able to have a higher level view of all the moving parts, and typically are great for, say, proposing integrations, or high level system design. Also, often specialists will solve a problem in their specialization, fit be damned. They need someone to derail them and say e.g. "this would be much, much easier if we leaned on MySQL to do this".
So, this feels like a baby and bathwater situation to me.
I'm sorry to read so deeply into your anecdote, but there's some interesting stuff to unpack.
> This can be nice in small teams, but usually leads to components nobody (not even the arrogant one) can understand
This describes nearly every company's MVP, so if you're thinking of a person in particular who had to cobble together some dynamic mess, chances are they have great regret for their design. But remember, tech debt is a luxury in these cases - often the alternative is no job or company, as the runway was exhausted, or investors were not impressed.
> A person believes they're the smartest, but not most knowledgeable, in the room.
I think there's no getting around this. In fact, TBH I hope my colleagues feel this way - I want them to advocate for things they think are better, and I don't want them to instead fall prey to their own insecurities.
It's actually kind of a little self-help bullshitty -- the "you can do anything" stuff -- but truly it's actually not awful advice. I guarantee there's someone you work with who has a better way of doing things, but isn't confident enough to endorse it.
I'm the worst for this. I firmly believe that given a totally novel problem in any domain that neither of us are familiar with. I will always solve it before you.
I also believe that whatever domain you're currently in I can outperform you in 5 years MAX.
It's crazy the bullshit we believe that 'feels' right day by day
I see this in my step mother. My family isn't very high in social standing, but she has a nursing degree and a long well paying career, better than anyone else in my family. Now that I have a CS degree with similar pay, she pays me respect but still tangentially riffs on things she only half understands.
9. Refuse to do any maintenance and only work on new projects.
10. Hide your actual productivity. IE: get done with your coding tasks in half the time, leaving other devs have to fix all the bugs that QA kick back. (This is probably a managerial issue, actually, but perpetuated by devs who do # 9.)
Sorry, but real life situation is infinitely more complicated.
Crybullies, manipulative people, people driven by greed to have power over others, hazing the new team member for whatever reason. Some are much more likely and zealous to report colleagues to the supervisors, some less. Some are more likely to be listened by the supervisors, some less.
In unlucky circumstances, couple of rounds of conversations with managers and suddenly you are the asshole nobody wants to work with.
> Developers can’t easily go back to where they were right
> before an interruption. They need to get into the mindset
> for development and then slowly trace back to where they
> left off. And every fellow developer knows that.
I used to think like that too, but after 10 years programming in many environments, now I'm inclined to disagree. If I cannot refocus immediately after interruption - I know I'm doing something wrong. Maybe the thing is too complex and must be cut down to smaller pieces, maybe I didn't keep enough notes or thinking through - anyhow nowadays I cannot work without a clear understanding of what simple piece of what complex piece I'm doing and where I've written down the other pieces I should do next.
Being able to reliably refocus after interruptions is an enviable skill.
I've learned some of that (especially when I was an intern divided 50/50 between development and interrupt-driven sys-admin :), but for me, interrupt cost seems to vary widely with the demands of the task and the nature interruption.
Web/GUI front-end work is usually very interruptible for me, for example. Usually, most of the time, I have in mind "I want to get to roughly this, and I just need to spend time getting or making the tools get there", and it's often easy to see where I left off. Coding seems usually mostly proceeding along a series of small tasks ("those controls are done, and next is that control"), or iterative refinement ("these two elements could be combined", or "this part of the layout is poor when rotated"), which are often very visible, and easy to get into.
However, if, for example, I'm in the middle of designing an algorithm, and trying to cover every case in a good form, and trying see opportunities, and I've mentally "paged in" a lot of domain-specific information and scenarios and such... an interruption at that moment with something that requires a very different domain to be paged in, and substantial thought... could really ruin the roll I was on with the algorithm. Even if I have a tentative skeleton with quick comments sprinkled through it, for the current thinking and known questions/opportunities. I'm simply not smart enough that I can't sometimes lose something with a big interruption at the wrong moment.
There's also the theory and meme of "flow" [1], but I don't understand it well enough to say whether it covers the impressions above.
To me that just sounds like you don't have tasks that require deep thought. And that you've developed habits to cope with interruptions, such as note-taking.
To turn a complex thing into a list of simple things can be done by experience as well as by deep thought. But don't think you could get that experience in 5-minute chunks of thinking. To get the experience you need deep thought.
Maybe set your sights higher if it's all easy to you? Or enjoy the fruits of experience, of course.
If I cannot refocus immediately after interruption - I know I'm doing something wrong.
This can be a sign that code needs to be reorganized. I've seen a number of really good coders in their 20's who are admirable for brilliant insights. However, they fall into this pattern of thinking of themselves as invincible, and they take on tasks where they are doing the "heavy lifting" of remembering tons of details all at once.
If you can lift 400 X's by hand, then you could easily lift 4000 X's with the right tool.
One of my bosses kept a stack, explicitly, and used that to keep track of his excursions into sub and side tasks.
I used to say that being a good programmer was being a professional forgetter as much as a professional memorizer. Basically, you should be constantly reorganizing your code as you go, so that there's no danger that forgetting a detail will result in an error. In a way, it's like people who work on high platforms who take precautions so that one drop or one slip won't result in injury or fatality.
> Maybe the thing is too complex and must be cut down to smaller pieces
i suspect that for many, it's not necessarily their fault Thing is 'too complex' (though perhaps this is tangential); nor are they necessarily provided the opportunity, time or even permission to 'cut down to smaller pieces'. piles of work, looming deadlines and all that.
- Always very responsive to problems. Jumps straight on them.
- Every problem fixed another one seems to pop up.
- Eventually you dig into the code and problem space in detail and you find that in a very subtle, even complex way the whole thing is completely wrong, the problem space misunderstood and everything patched over with little fixes to get things working for a particular case.
In the end no system created by the person is useable without major remediation by another developer.
Imagine a competent developer writes a mostly correct system with few bugs, and that requires few fixes over time.
Management will likely perceive the first incompetent developer as better than the more competent one.
Why? Because the incompetent developer is seen to be fixing problems all the time, which is a positive thing.[1] (You could say his work is more 'salient' to management.)
Frustratingly, the incompetent guy comes off as a rock star.
[1] Ignorant of the fact that the problems were created by the developer himself.
You're attributing that bullet point to the wrong developer.
Here's a profile of a reviewer:
- Isn't paying sufficient attention to the code being submitted.
Don't get me wrong-- I've ripped away drywall to reveal nastiness before. But what you've described is systemic, and for that the reviewer must share some responsibility.
Sounds like insufficient testing to me. This kind of deep/far reaching issue should have been crashing tests written before others would have seen it.
Assuming that there is some testing in their work (if not; there's the answer), my guess would be that it's largely sanity testing of each functionality in a vaccuum. The coaching would probably be to demonstrate more integration-style testing, possibly using whatever tests caught system-level issues that the dev has pushed in the past.
> A team with a bad developer is way better off short one developer than it is with a bad element.
How do you know that you just didn't communicate your issues well to the person? Is there a way to help them, you and your relationship improve so that you can be a stronger team?
We all have blindspots and weaknesses, and weaknesses that fit together like puzzle-pieces tend to find each other until you resolve them.
The half-moon is only an illusion, the whole moon is still there. You just don't see it, and you need the whole.
I think #1 and #6 go hand in hand, and usually results in #2. If you disregard your team, and you're arrogant, your code will likely be sloppy as hell. In my opinion that makes you the worst member of the team.
I spoke with a coworker about this and we agreed that you just need to be humble as a software developer: we all are going to screw up, we don't all know all the answers, and we don't know why others in our teams say / know specific things, but we should not take their advise lightly it might of been a painful lesson for them to begin with!
>gives cryptic names for variables, or at best not self-explanatory
sure a big one. It's part of a category of small decisions that dramatically increase cognitive load when accumulated. Along with it:
>Passing many arguments into functions with names that have no relevance to their role inside the function, so you constantly have to look up which argument maps to which function param
>Needlessly reorganizing data structures or renaming variables so that it becomes more difficult to reason about the flow of data
Naming things isn't just the hardest problem in programming, it's also the quickest way to piss off your peers if you're lazy about it.
I’ve worked with people who will fight and argue over every. Single. Detail. It drives me insane and usually makes me quit faster than anything else when I encounter those people.
How everyone can be right, but everyone gets annoyed anyways.
Cast:
Developer A, a younger developer who is recognized company-wide as an expert in the latest features of blb++.
Developer B, an older developer who maintains widely used legacy code in blb++ involved in about 80% of a billion dollar multinational's profits.
Dev A: Your group should change the coding style in this application to the new standard.
Dev B: Sure. But since we don't have good Unit Test coverage in this area, we shouldn't just go in and do it by hand. I need to guarantee correctness. I've done a change this big before using a syntax driven automated code rewrite tool, and one can guarantee correctness if the code structure allows it. If you know of such a tool for blb++, you can help me out and we can do it.
(Background for the reader: No such tool exists for blb++ which can guarantee correctness. Such tools do exist for other languages in Dev B's work experience.)
Later on, Dev A is grousing about how Dev B is just coming up with esoteric excuses to do nothing. She's kind of put off. Dev B is put off, because he's kind of been accused of making stuff up, even though he's talking from a particularly interesting and valuable part of his work experience.
Dev A is correct, in that the new coding style is better, more efficient, and would even prevent mistakes going forwards. Dev B is correct, in that he really needs to guarantee correctness, especially if he's going to make a change that big which has no visible benefit to stakeholders. What's the takeaway?
In my experience people provide excuses because they're being addressed by management in a way that is unnecessarily negative and/or management is wanting to find "guilty people" and not work out which is the best person for the job of fixing things.
That the article is clearly refusing to even mention this casts a big shadow over the rest of its conclusions. Some of the other things are the result of personality (like taking credit or sloppiness) but making excuses is 100% context and a defensive coping strategy literally every time I have seen or done it.
>Most developers are enthusiastic people, but sometimes you may have the chance (or misfortune) to work with a negative one. Negativity is infectious
Western society has a weird optimism bias. I think it goes hand in hand with extroversion bias, and it keeps many people from being genuine.
>those developers are clearly at the top of Mount Stupid
Frankly, that's insulting. Being a negative or critical person does not make one stupid, on the contrary, I would argue that the skepticism that comes with negativity is an asset for engineering. This advice is carte blanche to dismiss criticism.
> We all know at least one developer who ... will always insist on following “best practices” without understanding why those practices are considered “best” (there is no such thing as best practices that adapt to every team)
For any developers out there recently starting on your path, I cannot stress the importance of taking the time to seek out best practices for new skills and technologies you pick up.
Find all the "best practices" you can, then ignore some of them for a while with some pilot code, then try to follow a combination of the ones that make most sense to you. Compare the two modules for legibility, clarity, maintainability and conciseness.
If, however, your team already has an entrenched way of doing things, don't be that jerk who comes to the party blasting their own music. Follow the existing style guides to a T and only offer advice for improvement after you've spent some time working with them.
Even if you immediately recognize a glaring problem in the way things are done, no one is going to take you seriously and you'll just come across as arrogant unless you already have rapport as a perceptive and helpful team member.
Take time to understand the culture around you, but don't, as this author suggests, ignore the tried and true devices of other cultures.
I'd like to add, in my experience some developers firmly (and sometimes loudly, judgementally) join a working environment and espouse best practices they've acquired from a cultural background they've worked in so far. Or read about, or watched a training course about. And they don't know (or care if) they are pushing things which are advertised as "best practice" in some domain or other, but aren't half as universally agreed upon as they think, and aren't half as effective or appropriate as they think in the new job.
My point is: Some "best practices" aren't as universally agreed upon as people think, and people are often thinking in a bubble.
If you're at a new job, and you see a glaring lack of what you've learned is "essential" best practice, I'd urge caution in assuming your new team are ignorant or that your managers are as clueless as you think at first, even if it looks messy and disorganised.
Of course they might be clueless! But it takes time and deep questioning to be sure.
Of course your experience should be brought into each new place you work. You're hired to bring in what you know, not just to fill a seat. By all means talk about your experience, about things you have actually done which worked well, and about what industry leaders are currently talking about.
But if you feel the need to "teach" everyone straight away how to work better, give it time and consider the possibility that people might have given it considerable thought and experience of their own. They might even be familiar with much of what you're talking about, and rejected it or found a different approach. (Or they might not - that's to be discovered.)
I say this because I've seen people turn up and, in effect, try to start fights long before they have spent the time to figure out (a) others in the team are quite experienced and familiar with the same practices but have decided on something else, (b) different industry bubbles actually do have different best practices for similar problems, and (c) they can't see some kinds of development strategy that are in use, because subtlety.
I was just imagining the opposites of these and remembering some of my favorite people I ever worked with. I've only ever worked with 2 developers who I didn't like, and they fit this list almost perfectly.
Individuals often have little control over these things, and they are indicative of deeper cultural incentives. Without transgressing some, nothing will get done in many orgs. I see it a lot in big money VC backed startups, much less so in bootstrapped businesses. It’s important to be non-judgmental of people doing these things and simply leave or master Machiavellian moves to clear a path to promotion as other players are, eg. via optics or rallying support to oust “toxic” rivals for the good of the team.
I agree. The system in place is to blame, and those people rose because they are just playing the game that is dealt to them.
I'm not so good at the Machievellian political aspect, so I personally opt to leave when I notice behaviors like this are rewarded in the current system. I also wonder if I was able to rise in an organization that functions like this, if I would b the type of person to actually root out that toxicity in the first place.
Game theory suggests this is true. Dog eat dog. But do you think this is because incentives are misaligned, or do you think that even successful bootstrapped businesses, if around long enough, will fall victim to this culture?
As mentioned above, either the code works or it doesn’t … but it needs to work in combination with all the code being added to the codebase by your teammates.
That is Linus' job (or one of his trusted lieutenants). Kernel contributors generally do not interact with each other directly. There are simply too many kernel contributors to hold all kinds of "team meetings". The problems that the article mentions, exist mostly in a corporate environment. Virtual, distributed teams generally do not have these problems.
Software engineering is probably the most collaborative work in today’s world.
Yes, but successful software, such as the linux kernel, is not developed in the way he believes it is. What corporate IT typically does, is certainly not a reference.
A manager who doesn’t understand this is a manager who doesn’t understand software engineering.
A manager who does not read, evaluate, and merge pull requests, is not a manager; and does indeed not understand software engineering. The article complains about the side effects of one particular, rather outdated approach to software engineering. You will, for example, not hear the PostgreSQL or the Debian team complain about that kind of issues.
From my experience at various companies, "technical managers" fit well into most of these categories. Because actively coding and managing a team of multiple developers can bring most of these issues out of you. Example: "getting away with your architectural decisions because you are presenting your ideas with a managerial authority and ignoring better solutions presented by other senior developers."
[+] [-] vharuck|7 years ago|reply
The real problem is they believe "lazy" coworkers will eventually be below them in every subject. They may seek out colleagues' advice some times, but likely will never return because they "get it" now."
They'll act like a "jack and master of all trades." This can be nice in small teams, but usually leads to components nobody (not even the arrogant one) can understand let alone maintain. So experts need to be brought in, anyway.
These people let the quick ascent of "Mount Ignorance" multiple subjects get to their head. No such thing as a Renaissance man anymore.
Sadly, I'm that flavor of arrogance.
[+] [-] ltbarcly3|7 years ago|reply
- let people finish their statement: If you don't let someone finish and you interrupt, they will decide that you are just refusing to hear them out rather than disagreeing. It doesn't matter if you can prove mathematically with extensive sources and footnotes, most of the time they won't be able to accept that you understood their point and showed it to be flawed.
- pause long enough after they speak: Again, if you instantly explain why they are wrong, most of the time other people will not be able to handle this. They will decide you didn't actually consider what they said. It doesn't matter what is actually true, and if you somehow do convince them that you are right they will be doubly resistant since you are making them feel stupid on top of everything else. A huge benefit of this and the previous bullet is that you will often find that at first you misinterpreted what the person was saying, so you were about to disagree for no reason.
- don't force them to admit to themselves that they were wrong: if you let people 'save face' they can just get on board and agree with you. If you force them to grapple with being wrong they will be difficult and will hate your guts. It may seem silly, but replying 'I don't think that will work because ...' is going to be the source of turmoil, when saying 'Interesting. Previously we did something similar to that but we had a problem where ...' is going to win the other person over instantly most of the time. Later they will see that they were wrong, but you didn't rub their nose in it and force them to grapple with it in a social setting where they are going to have to feel shame.
Failure to do these things is just what people mean whenever they say someone is arrogant.
[+] [-] emsal|7 years ago|reply
I'm not suggesting you transition into becoming a PM or Architect or anything like that, just saying that developers like you count, too. If you have a decent work ethic, then you and your unique brand of knowledge-seeking have something to bring to the table.
[+] [-] balabaster|7 years ago|reply
As you advance up the mountain, you will learn to see complexity simply. When you make this realization, your components will simplify dramatically. You must learn to see simply before you can design simply. It just takes time. There's nothing wrong with this, humility doesn't mean giving up your belief that you're capable of anything.
We were all born without any knowledge. We all learned everything we needed to know to get where we are today. We've put men on the moon. We've sent probes to escape our solar system. We've sent submarines to the bottom of the ocean. Humans have the capability to do anything we put our minds to. You can too. Everything you understand today, you've learned in the short lifespan you've had. Today you will learn more, and tomorrow and the next. Just because you find humility in your place, doesn't mean you're not capable of anything.
[+] [-] elmomle|7 years ago|reply
In fact, I wonder if the narcissism you speak of might have more to do with insecurity, deep down. In my experience, when I see myself taking a behavior that I consciously am against, the cause tends to be emotional and the solution tends to be to gently, curiously observe those situations and start questioning how I feel. When I love and take care of my emotional world, it becomes way easier to interact in a way I feel is more optimal on the fly.
[+] [-] RyanDagg|7 years ago|reply
[+] [-] blackflame7000|7 years ago|reply
[+] [-] thegayngler|7 years ago|reply
I was quite sour over the fact that I felt like during the interview process I was lied to about the position and what it would entail. Naturally, I was a bit salty about it and the fact that people were doing things that I would get criticized for. It ultimately hurt my confidence in myself. This made me exhibit most if not all of these traits during my stay at this company. I was trying to make lemons into lemonade. Ultimately I was able help us get on the right path and I was happy with my contributions to the team even if it did ruffle feathers and those people hated me afterwards. I took their criticism and I still try to use it to be a better person to work with.
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] say-vagnes|7 years ago|reply
However, generalists are a very useful component of a team. They tend to be able to have a higher level view of all the moving parts, and typically are great for, say, proposing integrations, or high level system design. Also, often specialists will solve a problem in their specialization, fit be damned. They need someone to derail them and say e.g. "this would be much, much easier if we leaned on MySQL to do this".
So, this feels like a baby and bathwater situation to me.
I'm sorry to read so deeply into your anecdote, but there's some interesting stuff to unpack.
> This can be nice in small teams, but usually leads to components nobody (not even the arrogant one) can understand
This describes nearly every company's MVP, so if you're thinking of a person in particular who had to cobble together some dynamic mess, chances are they have great regret for their design. But remember, tech debt is a luxury in these cases - often the alternative is no job or company, as the runway was exhausted, or investors were not impressed.
> A person believes they're the smartest, but not most knowledgeable, in the room.
I think there's no getting around this. In fact, TBH I hope my colleagues feel this way - I want them to advocate for things they think are better, and I don't want them to instead fall prey to their own insecurities.
It's actually kind of a little self-help bullshitty -- the "you can do anything" stuff -- but truly it's actually not awful advice. I guarantee there's someone you work with who has a better way of doing things, but isn't confident enough to endorse it.
Anyhow... thanks for the writing prompt? ;)
[+] [-] bgroat|7 years ago|reply
I also believe that whatever domain you're currently in I can outperform you in 5 years MAX.
It's crazy the bullshit we believe that 'feels' right day by day
[+] [-] dgzl|7 years ago|reply
[+] [-] jcranberry|7 years ago|reply
[+] [-] daveFNbuck|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] chooseaname|7 years ago|reply
10. Hide your actual productivity. IE: get done with your coding tasks in half the time, leaving other devs have to fix all the bugs that QA kick back. (This is probably a managerial issue, actually, but perpetuated by devs who do # 9.)
[+] [-] expertentipp|7 years ago|reply
Crybullies, manipulative people, people driven by greed to have power over others, hazing the new team member for whatever reason. Some are much more likely and zealous to report colleagues to the supervisors, some less. Some are more likely to be listened by the supervisors, some less.
In unlucky circumstances, couple of rounds of conversations with managers and suddenly you are the asshole nobody wants to work with.
[+] [-] Dzugaru|7 years ago|reply
> before an interruption. They need to get into the mindset
> for development and then slowly trace back to where they
> left off. And every fellow developer knows that.
I used to think like that too, but after 10 years programming in many environments, now I'm inclined to disagree. If I cannot refocus immediately after interruption - I know I'm doing something wrong. Maybe the thing is too complex and must be cut down to smaller pieces, maybe I didn't keep enough notes or thinking through - anyhow nowadays I cannot work without a clear understanding of what simple piece of what complex piece I'm doing and where I've written down the other pieces I should do next.
[+] [-] neilv|7 years ago|reply
I've learned some of that (especially when I was an intern divided 50/50 between development and interrupt-driven sys-admin :), but for me, interrupt cost seems to vary widely with the demands of the task and the nature interruption.
Web/GUI front-end work is usually very interruptible for me, for example. Usually, most of the time, I have in mind "I want to get to roughly this, and I just need to spend time getting or making the tools get there", and it's often easy to see where I left off. Coding seems usually mostly proceeding along a series of small tasks ("those controls are done, and next is that control"), or iterative refinement ("these two elements could be combined", or "this part of the layout is poor when rotated"), which are often very visible, and easy to get into.
However, if, for example, I'm in the middle of designing an algorithm, and trying to cover every case in a good form, and trying see opportunities, and I've mentally "paged in" a lot of domain-specific information and scenarios and such... an interruption at that moment with something that requires a very different domain to be paged in, and substantial thought... could really ruin the roll I was on with the algorithm. Even if I have a tentative skeleton with quick comments sprinkled through it, for the current thinking and known questions/opportunities. I'm simply not smart enough that I can't sometimes lose something with a big interruption at the wrong moment.
There's also the theory and meme of "flow" [1], but I don't understand it well enough to say whether it covers the impressions above.
[1] https://en.wikipedia.org/wiki/Flow_(psychology)
[+] [-] lolc|7 years ago|reply
To turn a complex thing into a list of simple things can be done by experience as well as by deep thought. But don't think you could get that experience in 5-minute chunks of thinking. To get the experience you need deep thought.
Maybe set your sights higher if it's all easy to you? Or enjoy the fruits of experience, of course.
[+] [-] stcredzero|7 years ago|reply
This can be a sign that code needs to be reorganized. I've seen a number of really good coders in their 20's who are admirable for brilliant insights. However, they fall into this pattern of thinking of themselves as invincible, and they take on tasks where they are doing the "heavy lifting" of remembering tons of details all at once.
If you can lift 400 X's by hand, then you could easily lift 4000 X's with the right tool.
One of my bosses kept a stack, explicitly, and used that to keep track of his excursions into sub and side tasks.
I used to say that being a good programmer was being a professional forgetter as much as a professional memorizer. Basically, you should be constantly reorganizing your code as you go, so that there's no danger that forgetting a detail will result in an error. In a way, it's like people who work on high platforms who take precautions so that one drop or one slip won't result in injury or fatality.
In other words, work smarter, not harder.
[+] [-] hnbroseph|7 years ago|reply
i suspect that for many, it's not necessarily their fault Thing is 'too complex' (though perhaps this is tangential); nor are they necessarily provided the opportunity, time or even permission to 'cut down to smaller pieces'. piles of work, looming deadlines and all that.
[+] [-] scandox|7 years ago|reply
- Easy going and pleasant.
- Really interested in programming and tech in general
- Talks intelligently about the problem at hand. Asks all the right questions. Agrees a plan of action in collaboration with colleagues.
- Creates systems that definitely appear to work
- Code looks pretty sane. Structure is right. Style seems good.
- Always very responsive to problems. Jumps straight on them.
- Every problem fixed another one seems to pop up.
- Eventually you dig into the code and problem space in detail and you find that in a very subtle, even complex way the whole thing is completely wrong, the problem space misunderstood and everything patched over with little fixes to get things working for a particular case.
In the end no system created by the person is useable without major remediation by another developer.
Anyone experienced this?
[+] [-] gerbilly|7 years ago|reply
Imagine a competent developer writes a mostly correct system with few bugs, and that requires few fixes over time.
Management will likely perceive the first incompetent developer as better than the more competent one.
Why? Because the incompetent developer is seen to be fixing problems all the time, which is a positive thing.[1] (You could say his work is more 'salient' to management.)
Frustratingly, the incompetent guy comes off as a rock star.
[1] Ignorant of the fact that the problems were created by the developer himself.
[+] [-] jancsika|7 years ago|reply
You're attributing that bullet point to the wrong developer.
Here's a profile of a reviewer:
- Isn't paying sufficient attention to the code being submitted.
Don't get me wrong-- I've ripped away drywall to reveal nastiness before. But what you've described is systemic, and for that the reviewer must share some responsibility.
[+] [-] user5994461|7 years ago|reply
Patches and fixes have accumulated in response to strange edge case and bugs you wouldn't believe if told.
The organization and the problem space have shifted somewhat over time. A few things could have been done differently in the new environment.
[+] [-] mahemm|7 years ago|reply
Assuming that there is some testing in their work (if not; there's the answer), my guess would be that it's largely sanity testing of each functionality in a vaccuum. The coaching would probably be to demonstrate more integration-style testing, possibly using whatever tests caught system-level issues that the dev has pushed in the past.
[+] [-] kyberias|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] maltesers|7 years ago|reply
[+] [-] asabjorn|7 years ago|reply
How do you know that you just didn't communicate your issues well to the person? Is there a way to help them, you and your relationship improve so that you can be a stronger team?
We all have blindspots and weaknesses, and weaknesses that fit together like puzzle-pieces tend to find each other until you resolve them.
The half-moon is only an illusion, the whole moon is still there. You just don't see it, and you need the whole.
[+] [-] giancarlostoro|7 years ago|reply
I spoke with a coworker about this and we agreed that you just need to be humble as a software developer: we all are going to screw up, we don't all know all the answers, and we don't know why others in our teams say / know specific things, but we should not take their advise lightly it might of been a painful lesson for them to begin with!
[+] [-] koboll|7 years ago|reply
>gives cryptic names for variables, or at best not self-explanatory
sure a big one. It's part of a category of small decisions that dramatically increase cognitive load when accumulated. Along with it:
>Passing many arguments into functions with names that have no relevance to their role inside the function, so you constantly have to look up which argument maps to which function param
>Needlessly reorganizing data structures or renaming variables so that it becomes more difficult to reason about the flow of data
Naming things isn't just the hardest problem in programming, it's also the quickest way to piss off your peers if you're lazy about it.
[+] [-] braythwayt|7 years ago|reply
I sometimes feel like I don't see anti-patterns as I go through my career, I fall over them and sprawl on the floor.
[+] [-] ourmandave|7 years ago|reply
[+] [-] finaliteration|7 years ago|reply
I’ve worked with people who will fight and argue over every. Single. Detail. It drives me insane and usually makes me quit faster than anything else when I encounter those people.
[+] [-] whttheuuu|7 years ago|reply
There are 2 types of developers: those who enjoy philosophizing about programming minutiae and then there are those who enjoy shipping products.
[+] [-] lawn|7 years ago|reply
[+] [-] stcredzero|7 years ago|reply
Cast:
Developer A, a younger developer who is recognized company-wide as an expert in the latest features of blb++.
Developer B, an older developer who maintains widely used legacy code in blb++ involved in about 80% of a billion dollar multinational's profits.
Dev A: Your group should change the coding style in this application to the new standard.
Dev B: Sure. But since we don't have good Unit Test coverage in this area, we shouldn't just go in and do it by hand. I need to guarantee correctness. I've done a change this big before using a syntax driven automated code rewrite tool, and one can guarantee correctness if the code structure allows it. If you know of such a tool for blb++, you can help me out and we can do it.
(Background for the reader: No such tool exists for blb++ which can guarantee correctness. Such tools do exist for other languages in Dev B's work experience.)
Later on, Dev A is grousing about how Dev B is just coming up with esoteric excuses to do nothing. She's kind of put off. Dev B is put off, because he's kind of been accused of making stuff up, even though he's talking from a particularly interesting and valuable part of his work experience.
Dev A is correct, in that the new coding style is better, more efficient, and would even prevent mistakes going forwards. Dev B is correct, in that he really needs to guarantee correctness, especially if he's going to make a change that big which has no visible benefit to stakeholders. What's the takeaway?
[+] [-] arandr0x|7 years ago|reply
That the article is clearly refusing to even mention this casts a big shadow over the rest of its conclusions. Some of the other things are the result of personality (like taking credit or sloppiness) but making excuses is 100% context and a defensive coping strategy literally every time I have seen or done it.
[+] [-] fromthestart|7 years ago|reply
Western society has a weird optimism bias. I think it goes hand in hand with extroversion bias, and it keeps many people from being genuine.
>those developers are clearly at the top of Mount Stupid
Frankly, that's insulting. Being a negative or critical person does not make one stupid, on the contrary, I would argue that the skepticism that comes with negativity is an asset for engineering. This advice is carte blanche to dismiss criticism.
[+] [-] kakarot|7 years ago|reply
> We all know at least one developer who ... will always insist on following “best practices” without understanding why those practices are considered “best” (there is no such thing as best practices that adapt to every team)
For any developers out there recently starting on your path, I cannot stress the importance of taking the time to seek out best practices for new skills and technologies you pick up.
Find all the "best practices" you can, then ignore some of them for a while with some pilot code, then try to follow a combination of the ones that make most sense to you. Compare the two modules for legibility, clarity, maintainability and conciseness.
If, however, your team already has an entrenched way of doing things, don't be that jerk who comes to the party blasting their own music. Follow the existing style guides to a T and only offer advice for improvement after you've spent some time working with them.
Even if you immediately recognize a glaring problem in the way things are done, no one is going to take you seriously and you'll just come across as arrogant unless you already have rapport as a perceptive and helpful team member.
Take time to understand the culture around you, but don't, as this author suggests, ignore the tried and true devices of other cultures.
[+] [-] jlokier|7 years ago|reply
I'd like to add, in my experience some developers firmly (and sometimes loudly, judgementally) join a working environment and espouse best practices they've acquired from a cultural background they've worked in so far. Or read about, or watched a training course about. And they don't know (or care if) they are pushing things which are advertised as "best practice" in some domain or other, but aren't half as universally agreed upon as they think, and aren't half as effective or appropriate as they think in the new job.
My point is: Some "best practices" aren't as universally agreed upon as people think, and people are often thinking in a bubble.
If you're at a new job, and you see a glaring lack of what you've learned is "essential" best practice, I'd urge caution in assuming your new team are ignorant or that your managers are as clueless as you think at first, even if it looks messy and disorganised.
Of course they might be clueless! But it takes time and deep questioning to be sure.
Of course your experience should be brought into each new place you work. You're hired to bring in what you know, not just to fill a seat. By all means talk about your experience, about things you have actually done which worked well, and about what industry leaders are currently talking about.
But if you feel the need to "teach" everyone straight away how to work better, give it time and consider the possibility that people might have given it considerable thought and experience of their own. They might even be familiar with much of what you're talking about, and rejected it or found a different approach. (Or they might not - that's to be discovered.)
I say this because I've seen people turn up and, in effect, try to start fights long before they have spent the time to figure out (a) others in the team are quite experienced and familiar with the same practices but have decided on something else, (b) different industry bubbles actually do have different best practices for similar problems, and (c) they can't see some kinds of development strategy that are in use, because subtlety.
[+] [-] daveFNbuck|7 years ago|reply
[+] [-] rojobuffalo|7 years ago|reply
Be humble, be kind.
[+] [-] harlanji|7 years ago|reply
[+] [-] okaramian|7 years ago|reply
I'm not so good at the Machievellian political aspect, so I personally opt to leave when I notice behaviors like this are rewarded in the current system. I also wonder if I was able to rise in an organization that functions like this, if I would b the type of person to actually root out that toxicity in the first place.
[+] [-] selflesssieve|7 years ago|reply
[+] [-] neokantian|7 years ago|reply
That is Linus' job (or one of his trusted lieutenants). Kernel contributors generally do not interact with each other directly. There are simply too many kernel contributors to hold all kinds of "team meetings". The problems that the article mentions, exist mostly in a corporate environment. Virtual, distributed teams generally do not have these problems.
Software engineering is probably the most collaborative work in today’s world.
Yes, but successful software, such as the linux kernel, is not developed in the way he believes it is. What corporate IT typically does, is certainly not a reference.
A manager who doesn’t understand this is a manager who doesn’t understand software engineering.
A manager who does not read, evaluate, and merge pull requests, is not a manager; and does indeed not understand software engineering. The article complains about the side effects of one particular, rather outdated approach to software engineering. You will, for example, not hear the PostgreSQL or the Debian team complain about that kind of issues.
[+] [-] CodeSheikh|7 years ago|reply