12 ms·

Almost 20 years of professional experience here: I fully agree with this list. I even want to add a few things: > Clever code isn't usually good code. Clarity

Almost 20 years of professional experience here: I fully agree with this list. I even want to add a few things: > Clever code isn't usually good code. Clarity trumps all other concerns. My measurement is "simple and clean" code. Is it simple and clean? No? make it so! > After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better. If a good developer you know, recommends someone they worked with: It's almost an instant hire. But for the rest, yeah, it's incredibly tough. One last thing I like to remind myself: "Good enough is always good enough". Sometimes "good enough" has a low bar, sometimes high. You always need to reach it, but never want to go too far above it.

deleted 6y ago
[deleted]
jka 6y ago
Your mention of simple and clean code makes me think of the excellent talk "Transforming Code into Beautiful, Idiomatic Python". Although it relates to Python programming, if the ideas and principles (and thoughtfulness and pace) from it could be applied to much more written code, then (I think) we as an industry and all our users would be in a better place. [1] - https://www.youtube.com/watch?v=OSGv2VnC0go https://www.youtube.com/watch?v=OSGv2VnC0go
- Chris_Newton 6y ago
  Possibly worth noting that the presentation there is a few years old now and appears to be using Python 2 for the examples, so some of the code wouldn’t be exactly the same in Python 3 even if the ideas still make sense. With that caveat, watching almost anything that Raymond Hettinger presents is positively correlated with improving programmer skill.
radicalbyte 6y ago
I'm also at 20 years, and he has hit the nail dead on. I can add a few things: * Operational considerations dominate language choice. * Architecture too. * Politics, leverage and all that MBA crap dominate all of that. * Language zealots are net negative idiots and need taking outside and shooting. * Actually apply that to all zealots. * The root cause of the above is often insecurity; and it can be coached / cultured away. * If your lead/management doesn't get that then they're in the wrong job, get out. * If you see shady consultant types and "thought leaders" talking about something, then it's just the latest bullshitchain. * If you see a junior developer say "this is easy", then let them learn the hard way, but manage expectations. * If you see Senior level engineers constantly say "this is easy" when the problem isn't clear, then run for the hills * The 10x engineer is only true in special cases and does not generalise. * That ^ is why you need to work together so everyone is doing their 10x task. * Incompetent engineers and bad actors can act as negative 10x engineers. * The vast majority of people on the outside of the team (consultant types) are worse than the above. With interviewing I have decent results just having an open form conversation, looking first for personality and drive and getting an idea of their technical knowledge by seeing how deep they can go (or if they even can go deep into a subject). References from someone competent dominate, mind.
- theshrike79 6y ago
  One more from me, with 20 years of experience. Some people are force multipliers. They make everyone around them more efficient. BUT people like this are hard to determine with Standard Performance Indicators. Personal anecdote: I had to fight tooth and nail to keep a junior coder in my team because "she wasn't performing well". Yes, she didn't commit often and her code quality was average at best. Tasks took longer than average to complete as well. But what she DID DO was keep the two auteur seat-of-their-pants 10x coders in her team focused and on task, made sure to ask the correct questions and had them document their work. She also took over their customer-facing stuff so the socially awkward 10x pair didn't need to do that. None of this showed up on standard performance indicators. Now she's a team lead at the same company, managing the two 10x-ers.
  - radicalbyte 6y ago
    Totally agree; I'm now very similar to your example, only I came from being one "the" 10x-er. Then I worked with another 10x-er at the same time as we had our first kid. With no sleep and no time to learn I could remain a 10x-er so transitioned into a Tech Lead (and am now moving towards CTO). Now I spent my time optimising/running the system of software creation and delivery, being the face and the glue - because hey, that's me.
- dvfjsdhgfv 6y ago
  > * The root cause of the above is often insecurity; and it can be coached / cultured away. It's definitely not true. Very often the root cause of zealotry is simply passion, enthusiasm especially for something new you start to like more and more every day, and at some point you start to have a false conviction - that it could solve all possible problems. Usually, zealots become more reasonable with time.
  - greyhair 6y ago
    In thirty five years, I have encountered three zealots that became worse over time, because their zealotry was seen by upper management as dedication and resolve, so they were rewarded. As we all know in engineering, positive feedback is bad. It was awful. But luckily only three times in thirty five years, so I have that going for me.
throwaway-8c93 6y ago
> After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better. My score is similar, and kind of agree. The eerie part is that the intuition can discern a good hire within 2 minutes with fairly high probability, and within 10 minutes with near certainty. The rest of the interview process is just padding to figure out whether the intuition is not wrong (it seldom is). That intuition is some mashup of the candidate speaking on point, pragmatism, non-equivocation, admission of ignorance on some topics, English proficiency (1), etc. It's also impossible to codify or quantify, hard to convey and non-transferable. (1) - here in Europe, English fluency, diction and (lack of) thick accent correlate highly with overall ability
- roguas 6y ago
  No, they do not. Or at the very least you should not draw conclusions like that. How do you corelate language skills with technical abilities? There is large group of people who even with perfect language skills is unable to shake off the accent as it is probably genetics/biology. Thats why you hear accent in "foreign" people after 20+ years. Please, trust your intuitions little less. Treat more of your impressions as anecdotal :)
mabbo 6y ago
> If a good developer you know, recommends someone they worked with: It's almost an instant hire. But for the rest, yeah, it's incredibly tough. A talk I watched recently by Ijeoma Oluo made a point I had never considered before: statistically, most people refer friends, and most friends are of a similar background, race, culture, gender, etc. It's not intentional- people aren't going out of their way to only refer people like them- but it's measurable. And those referrals are more likely to be hired (they're good people, that's why they were referred!) Which means referral bonuses have a perverse incentive of making a company less diverse. I don't even have a good answer to what to do about it, because you're right: referrals are a great way to hire good developers. It's just got this big worrying downside that leaves me bothered.
- carlhjerpe 6y ago
  What is the upside of a higly diversified worksforce? Where I work we're all white males age 20-60 except accounting, they're white females around age 30. What's bad about this? What value does it bring to diversify, what should we look for and why is it important? Or are we too small to need diversifying yet with only about 30 employees?
  - mabbo 6y ago
    If you don't see the value in having a diverse workforce and company at any scale, I doubt anything I can say will convince you. There's enough research out there showing the benefits, if you're willing to take just a few minutes to go look for it. Your competitors will read that research. edit: carlhjerpe is right- this is super condescending. Downvote me.
    - carlhjerpe 6y ago
      That's very condescending. I'm asking because I don't see why my colleagues would be any better than they are if they were black, brown, jewish, muslim, female in various combinations, maybe I hold my colleaguestoo high?
      - 6y ago
gilbetron 6y ago
I have 30 years of pro experience, so I'm like you plus another 10 years of confusion. I agree with the list as well, and like your (and others) additions. I especially feel that parts about zealotry. The worst are Medium developers, those with a Medium amount (3-7 years) of experience that get their dogma from Medium articles.
DrBazza 6y ago
25 years for me > Clever code isn't usually good code. Clarity trumps all other concerns. Agreed, with exceptions... the problem domain matters. HFT code definitely demands code that is clever, but isn't clear such as bit twiddling, template tricks, and very architecture specific solutions. Gaming - Carmack's fast inverse square root. Compilers - Duff's device. I'm sure there are others. I'd add one: Someone else did it first and better. Pretty much everything you'll encounter that's non-trivial, is likely an algorithm and done by someone else better, correctly, and faster. There's nothing wrong with knowing the algorithms, but Knuth, Hoare, et al. probably did it first, and correctly. Don't be afraid to find the best algorithm implementation in your language.
deanCommie 6y ago
Another 20 year veteran here. (though don't picture a greybeard, I started professionally at 15) The big lesson for me over the last 5 years now that I also operate my code is design patterns. I think most Software people start with hating design patterns, then some fall in love with them, then eventually some of us fall out of love again. The advice would be: "Optimize code cleanliness and readability for reading at 2am in the middle of a production issue when you're trying to understand just exactly how the system got into that state that you didn't think was possible." That means every jump to another class and every jump to an interface with multiple implementations is a distraction. You should still of course create modular separations for testability and clarity. But that line is way higher than the Uncle Bob "If a function is more than 4 lines long you should refactor it". For complex mission critical pieces of logic, overindex on procedural execution, with paragraphs of comments explaining why each line is doing what it's doing. Actually, another wisdom about comments: I went from thinking "Comments are great!" to "Comments are terrible, and are liars, write self-documenting code" to "Comments are literally an opportunity for you to speak directly to the person coming after you, and explain in clear plain english WHY you made the choices you did, what tradeoffs you considered and dismissed, what compromises you made, and what external factors led to those decisions." Comments don't need to be passive voice professional corporate speak. Nor do they need to make you sound smart or clever. Speak directly to your audience of future more junior engineers. Exception messages too (sanitize all exceptions before they get to the customer, of course)
- lytefm 6y ago
  > I went from thinking "Comments are great!" to "Comments are terrible, and are liars, write self-documenting code" to "Comments are literally an opportunity for you to speak directly to the person coming after you, and explain in clear plain english WHY you made the choices you did, what tradeoffs you considered and dismissed, what compromises you made, and what external factors led to those decisions." Wholeheartedly agree. Also, debugging logs for that same purpose can be great. > Speak directly to your audience of future more junior engineers. Often enough, that person might be yourself. I've been very grateful about my own comments in code areas that handled some obscure edge cases. > That means every jump to another class and every jump to an interface with multiple implementations is a distraction. Not to mention multiple layers of abstract base classes. I'd say „write your code such that you'll only ever need one IDE jump out of the current scope (and back in) to figure out what's going on“

deleted 6y ago

[deleted]

jka 6y ago

Your mention of simple and clean code makes me think of the excellent talk "Transforming Code into Beautiful, Idiomatic Python". Although it relates to Python programming, if the ideas and principles (and thoughtfulness and pace) from it could be applied to much more written code, then (I think) we as an industry and all our users would be in a better place. [1] - https://www.youtube.com/watch?v=OSGv2VnC0go https://www.youtube.com/watch?v=OSGv2VnC0go

Chris_Newton 6y ago
Possibly worth noting that the presentation there is a few years old now and appears to be using Python 2 for the examples, so some of the code wouldn’t be exactly the same in Python 3 even if the ideas still make sense. With that caveat, watching almost anything that Raymond Hettinger presents is positively correlated with improving programmer skill.

radicalbyte 6y ago

I'm also at 20 years, and he has hit the nail dead on. I can add a few things: * Operational considerations dominate language choice. * Architecture too. * Politics, leverage and all that MBA crap dominate all of that. * Language zealots are net negative idiots and need taking outside and shooting. * Actually apply that to all zealots. * The root cause of the above is often insecurity; and it can be coached / cultured away. * If your lead/management doesn't get that then they're in the wrong job, get out. * If you see shady consultant types and "thought leaders" talking about something, then it's just the latest bullshitchain. * If you see a junior developer say "this is easy", then let them learn the hard way, but manage expectations. * If you see Senior level engineers constantly say "this is easy" when the problem isn't clear, then run for the hills * The 10x engineer is only true in special cases and does not generalise. * That ^ is why you need to work together so everyone is doing their 10x task. * Incompetent engineers and bad actors can act as negative 10x engineers. * The vast majority of people on the outside of the team (consultant types) are worse than the above. With interviewing I have decent results just having an open form conversation, looking first for personality and drive and getting an idea of their technical knowledge by seeing how deep they can go (or if they even can go deep into a subject). References from someone competent dominate, mind.

theshrike79 6y ago
One more from me, with 20 years of experience. Some people are force multipliers. They make everyone around them more efficient. BUT people like this are hard to determine with Standard Performance Indicators. Personal anecdote: I had to fight tooth and nail to keep a junior coder in my team because "she wasn't performing well". Yes, she didn't commit often and her code quality was average at best. Tasks took longer than average to complete as well. But what she DID DO was keep the two auteur seat-of-their-pants 10x coders in her team focused and on task, made sure to ask the correct questions and had them document their work. She also took over their customer-facing stuff so the socially awkward 10x pair didn't need to do that. None of this showed up on standard performance indicators. Now she's a team lead at the same company, managing the two 10x-ers.
- radicalbyte 6y ago
  Totally agree; I'm now very similar to your example, only I came from being one "the" 10x-er. Then I worked with another 10x-er at the same time as we had our first kid. With no sleep and no time to learn I could remain a 10x-er so transitioned into a Tech Lead (and am now moving towards CTO). Now I spent my time optimising/running the system of software creation and delivery, being the face and the glue - because hey, that's me.
dvfjsdhgfv 6y ago
> * The root cause of the above is often insecurity; and it can be coached / cultured away. It's definitely not true. Very often the root cause of zealotry is simply passion, enthusiasm especially for something new you start to like more and more every day, and at some point you start to have a false conviction - that it could solve all possible problems. Usually, zealots become more reasonable with time.
- greyhair 6y ago
  In thirty five years, I have encountered three zealots that became worse over time, because their zealotry was seen by upper management as dedication and resolve, so they were rewarded. As we all know in engineering, positive feedback is bad. It was awful. But luckily only three times in thirty five years, so I have that going for me.

throwaway-8c93 6y ago

> After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better. My score is similar, and kind of agree. The eerie part is that the intuition can discern a good hire within 2 minutes with fairly high probability, and within 10 minutes with near certainty. The rest of the interview process is just padding to figure out whether the intuition is not wrong (it seldom is). That intuition is some mashup of the candidate speaking on point, pragmatism, non-equivocation, admission of ignorance on some topics, English proficiency (1), etc. It's also impossible to codify or quantify, hard to convey and non-transferable. (1) - here in Europe, English fluency, diction and (lack of) thick accent correlate highly with overall ability

roguas 6y ago
No, they do not. Or at the very least you should not draw conclusions like that. How do you corelate language skills with technical abilities? There is large group of people who even with perfect language skills is unable to shake off the accent as it is probably genetics/biology. Thats why you hear accent in "foreign" people after 20+ years. Please, trust your intuitions little less. Treat more of your impressions as anecdotal :)

mabbo 6y ago

> If a good developer you know, recommends someone they worked with: It's almost an instant hire. But for the rest, yeah, it's incredibly tough. A talk I watched recently by Ijeoma Oluo made a point I had never considered before: statistically, most people refer friends, and most friends are of a similar background, race, culture, gender, etc. It's not intentional- people aren't going out of their way to only refer people like them- but it's measurable. And those referrals are more likely to be hired (they're good people, that's why they were referred!) Which means referral bonuses have a perverse incentive of making a company less diverse. I don't even have a good answer to what to do about it, because you're right: referrals are a great way to hire good developers. It's just got this big worrying downside that leaves me bothered.

carlhjerpe 6y ago
What is the upside of a higly diversified worksforce? Where I work we're all white males age 20-60 except accounting, they're white females around age 30. What's bad about this? What value does it bring to diversify, what should we look for and why is it important? Or are we too small to need diversifying yet with only about 30 employees?
- mabbo 6y ago
  If you don't see the value in having a diverse workforce and company at any scale, I doubt anything I can say will convince you. There's enough research out there showing the benefits, if you're willing to take just a few minutes to go look for it. Your competitors will read that research. edit: carlhjerpe is right- this is super condescending. Downvote me.
  - carlhjerpe 6y ago
    That's very condescending. I'm asking because I don't see why my colleagues would be any better than they are if they were black, brown, jewish, muslim, female in various combinations, maybe I hold my colleaguestoo high?
    - 6y ago

gilbetron 6y ago

I have 30 years of pro experience, so I'm like you plus another 10 years of confusion. I agree with the list as well, and like your (and others) additions. I especially feel that parts about zealotry. The worst are Medium developers, those with a Medium amount (3-7 years) of experience that get their dogma from Medium articles.

DrBazza 6y ago

25 years for me > Clever code isn't usually good code. Clarity trumps all other concerns. Agreed, with exceptions... the problem domain matters. HFT code definitely demands code that is clever, but isn't clear such as bit twiddling, template tricks, and very architecture specific solutions. Gaming - Carmack's fast inverse square root. Compilers - Duff's device. I'm sure there are others. I'd add one: Someone else did it first and better. Pretty much everything you'll encounter that's non-trivial, is likely an algorithm and done by someone else better, correctly, and faster. There's nothing wrong with knowing the algorithms, but Knuth, Hoare, et al. probably did it first, and correctly. Don't be afraid to find the best algorithm implementation in your language.

deanCommie 6y ago

Another 20 year veteran here. (though don't picture a greybeard, I started professionally at 15) The big lesson for me over the last 5 years now that I also operate my code is design patterns. I think most Software people start with hating design patterns, then some fall in love with them, then eventually some of us fall out of love again. The advice would be: "Optimize code cleanliness and readability for reading at 2am in the middle of a production issue when you're trying to understand just exactly how the system got into that state that you didn't think was possible." That means every jump to another class and every jump to an interface with multiple implementations is a distraction. You should still of course create modular separations for testability and clarity. But that line is way higher than the Uncle Bob "If a function is more than 4 lines long you should refactor it". For complex mission critical pieces of logic, overindex on procedural execution, with paragraphs of comments explaining why each line is doing what it's doing. Actually, another wisdom about comments: I went from thinking "Comments are great!" to "Comments are terrible, and are liars, write self-documenting code" to "Comments are literally an opportunity for you to speak directly to the person coming after you, and explain in clear plain english WHY you made the choices you did, what tradeoffs you considered and dismissed, what compromises you made, and what external factors led to those decisions." Comments don't need to be passive voice professional corporate speak. Nor do they need to make you sound smart or clever. Speak directly to your audience of future more junior engineers. Exception messages too (sanitize all exceptions before they get to the customer, of course)

lytefm 6y ago
> I went from thinking "Comments are great!" to "Comments are terrible, and are liars, write self-documenting code" to "Comments are literally an opportunity for you to speak directly to the person coming after you, and explain in clear plain english WHY you made the choices you did, what tradeoffs you considered and dismissed, what compromises you made, and what external factors led to those decisions." Wholeheartedly agree. Also, debugging logs for that same purpose can be great. > Speak directly to your audience of future more junior engineers. Often enough, that person might be yourself. I've been very grateful about my own comments in code areas that handled some obscure edge cases. > That means every jump to another class and every jump to an interface with multiple implementations is a distraction. Not to mention multiple layers of abstract base classes. I'd say „write your code such that you'll only ever need one IDE jump out of the current scope (and back in) to figure out what's going on“