3 ms·

The point about "incompetent people" is a bit harsh. "Competence" is rarely boolean - some people are smarter, some are less smart, but may have other qualities

by rob74 3y ago

The point about "incompetent people" is a bit harsh. "Competence" is rarely boolean - some people are smarter, some are less smart, but may have other qualities (e.g. being more thorough), some may not be that familiar with a certain technology etc.; that code you have to work on may look the way it looks because it had to be adapted several times to changing requirements without enough time to refactor it properly, not because the person who wrote it was incompetent. There are already enough young developers leaving university full of self-confidence thinking they are God's gift to the job market, so maybe a word or two about giving people the benefit of doubt before classifying them as incompetent is in order. That's not to say there aren't really incompetent people, but you should avoid jumping to conclusions too early...

quietbritishjim 3y ago
Maybe, but the people I have worked with have been pretty heavily bimodal, especially by the senior level - many people in the "competent" bucket varied a bit but generally produced workable code (maintainable as well as works now). But there is a distinct class of senior engineer that produces awful code that is hopeless to work with later. Most frustratingly, it does actually work for the current task so those outside the system will only see problems with the later devs to work on it.
- Aeolun 3y ago
  > But there is a distinct class of senior engineer that produces awful code that is hopeless to work with later The longer I work on stuff the more I worry this is me. I thought it was the code coming before me, but the code after seems just as error prone.
  - BigJono 3y ago
    There's a really easy way to tell. If I say something like "I've got my sales history in a database and need to graph how many widgets I've sold over time", do you start thinking about concepts and code, or do you start drooling and typing "npm database npm graph npm widget..."?
    - hotnfresh 3y ago
      Seasoned pro-tier for that specific sort of problem is just batch-exporting to excel and letting it do the graphing, or hacking something up in Power BI or whatever.
      - throw555chip 3y ago
        One point to make about thrown together solutions, in the following video: https://www.youtube.com/watch?v=TmhQCQr_DCA https://www.youtube.com/watch?v=TmhQCQr_DCA at time 8:32 he changes Units Sold column from Decimal to Whole Number. For the trivial example, it would probably be fine but it could also be a costly mistake in other scenarios.
  - the_sleaze9 3y ago
    We all start from somewhere and nobody was born starting from perfect. First label your fundamental concerns. You cannot improve what you don't measure. Error-prone code? First number the errors then classify the errors. Are your errors related to typos or do they come from not handling variable input gracefully? Now reduce your numbers by consciously finding typos, or by consciously mapping out just what inputs could possibly come in. Miss one? Write it down and never miss it again. Meetings? How many times do you get "well actually'd"? What specific areas do you get asked questions about? Coworkers? How many times do you get asked for help? How many times do you ask the same question -with or w/o a subtle variation- more than once? How often do you reach out to just shoot the shit? How often does someone approach you for water cooler talk? Or (more likely) you just _feel like you aren't competent. Having hard numbers will go very far in getting a more objective viewpoint there.
jameshart 3y ago
The hard truth: Some days, you’ll be the incompetent person.
- rob74 3y ago
  Or, to put it in the immortal words of U2, some days are better than others (https://genius.com/U2-some-days-are-better-than-others-lyrics https://genius.com/U2-some-days-are-better-than-others-lyric...)
- manicennui 3y ago
  Being wrong occasionally is human. It is not the same as being incompetent. There truly are numerous people in software engineering who don't know what they are doing at all.
kagakuninja 3y ago
On my current job, one guy took over a month to "write more tests for service X". He was finally fired (took over a year despite being clearly incompetent, and they had multiple opportunities to not renew his contract). After that, I saw that he had only written 6 tests, which were quick copy-pastes, and largely useless. Maybe this guy had some positive qualities, but writing code was not one of them. Another guy on this small team writes garbage code. Like "if (condition) true else false". He does have some redeeming qualities, but has caused huge amounts of bugs and tech debt despite being one of the most senior devs on the team. My code is not perfect, I've done the occasional bonehead maneuver and had dunning-kruger when I was young, but there is just no comparison. The majority of devs on this team are not shit; we know who the shitty ones are.
xcv123 3y ago
> not because the person who wrote it was incompetent. You haven't seen it yet. Some developers should be barred from the industry. Criminally incompetent.
deterministic 3y ago
Nope. There are extremely incompetent software developers out there. People who are so incompetent that removing them from the team increase the productivity of the team. After 30 years of working on software teams around the world my conclusion is that 1 in 10 developers are really good and worth working with. 8 in 10 are OK for routine work but don’t let them make any high level architectural decisions. And 1 in 10 are so incompetent that they should be removed from the team.

by rob74 3y ago

quietbritishjim 3y ago

Maybe, but the people I have worked with have been pretty heavily bimodal, especially by the senior level - many people in the "competent" bucket varied a bit but generally produced workable code (maintainable as well as works now). But there is a distinct class of senior engineer that produces awful code that is hopeless to work with later. Most frustratingly, it does actually work for the current task so those outside the system will only see problems with the later devs to work on it.

Aeolun 3y ago
> But there is a distinct class of senior engineer that produces awful code that is hopeless to work with later The longer I work on stuff the more I worry this is me. I thought it was the code coming before me, but the code after seems just as error prone.
- BigJono 3y ago
  There's a really easy way to tell. If I say something like "I've got my sales history in a database and need to graph how many widgets I've sold over time", do you start thinking about concepts and code, or do you start drooling and typing "npm database npm graph npm widget..."?
  - hotnfresh 3y ago
    Seasoned pro-tier for that specific sort of problem is just batch-exporting to excel and letting it do the graphing, or hacking something up in Power BI or whatever.
    - throw555chip 3y ago
      One point to make about thrown together solutions, in the following video: https://www.youtube.com/watch?v=TmhQCQr_DCA https://www.youtube.com/watch?v=TmhQCQr_DCA at time 8:32 he changes Units Sold column from Decimal to Whole Number. For the trivial example, it would probably be fine but it could also be a costly mistake in other scenarios.
- the_sleaze9 3y ago
  We all start from somewhere and nobody was born starting from perfect. First label your fundamental concerns. You cannot improve what you don't measure. Error-prone code? First number the errors then classify the errors. Are your errors related to typos or do they come from not handling variable input gracefully? Now reduce your numbers by consciously finding typos, or by consciously mapping out just what inputs could possibly come in. Miss one? Write it down and never miss it again. Meetings? How many times do you get "well actually'd"? What specific areas do you get asked questions about? Coworkers? How many times do you get asked for help? How many times do you ask the same question -with or w/o a subtle variation- more than once? How often do you reach out to just shoot the shit? How often does someone approach you for water cooler talk? Or (more likely) you just _feel like you aren't competent. Having hard numbers will go very far in getting a more objective viewpoint there.

jameshart 3y ago

The hard truth: Some days, you’ll be the incompetent person.

rob74 3y ago
Or, to put it in the immortal words of U2, some days are better than others (https://genius.com/U2-some-days-are-better-than-others-lyrics https://genius.com/U2-some-days-are-better-than-others-lyric...)
manicennui 3y ago
Being wrong occasionally is human. It is not the same as being incompetent. There truly are numerous people in software engineering who don't know what they are doing at all.

kagakuninja 3y ago

On my current job, one guy took over a month to "write more tests for service X". He was finally fired (took over a year despite being clearly incompetent, and they had multiple opportunities to not renew his contract). After that, I saw that he had only written 6 tests, which were quick copy-pastes, and largely useless. Maybe this guy had some positive qualities, but writing code was not one of them. Another guy on this small team writes garbage code. Like "if (condition) true else false". He does have some redeeming qualities, but has caused huge amounts of bugs and tech debt despite being one of the most senior devs on the team. My code is not perfect, I've done the occasional bonehead maneuver and had dunning-kruger when I was young, but there is just no comparison. The majority of devs on this team are not shit; we know who the shitty ones are.

xcv123 3y ago

> not because the person who wrote it was incompetent. You haven't seen it yet. Some developers should be barred from the industry. Criminally incompetent.

deterministic 3y ago

Nope. There are extremely incompetent software developers out there. People who are so incompetent that removing them from the team increase the productivity of the team. After 30 years of working on software teams around the world my conclusion is that 1 in 10 developers are really good and worth working with. 8 in 10 are OK for routine work but don’t let them make any high level architectural decisions. And 1 in 10 are so incompetent that they should be removed from the team.