5 ms·

I work with an expert beginner and I don't know how he's survived. He's got about 30 years of experience, but writes code like he's got 1 year of experience.

I work with an expert beginner and I don't know how he's survived. He's got about 30 years of experience, but writes code like he's got 1 year of experience. His code has absolutely no sense of quality, doesn't employ any sort of standard design patterns or style, has no semblance of architecture and is an absolute hacky rats nest of code that falls apart with any change because of how interdependent it is. The other day I was sent some of his updated code, which had no version control and had randomly added an extra 150 files to the project. It turns out the majority of those files where duplicated from elsewhere in the project and apparently it was my job to find where the changes were among that mess. It's like he learnt to program decades ago and then never opened a book or looked at anyone else's code since.

BossingAround 6y ago
"If it ain't broke"... :))
ohazi 6y ago
In flying, logged hours are often used as an indicator of experience. A quip I've heard from at least two instructors: "You can fly 400 hours, or you can fly the same hour 400 times." Sounds like your coworker has had the same first year of experience 30 times...
twic 6y ago
And he's still got a job. So who's the real genius here? I don't want to be that guy, and i don't want to work with that guy, but i have to confess to a certain jealousy that people like him have figured out how to sit back and just phone it in and collect pay cheques for thirty years.
- cyberdrunk 6y ago
  If he has any degree of self-awareness then perhaps those 30 years were riddled with anxiety over losing the job and not being able to find another one.
  - thatoneuser 6y ago
    He's had the job for 30 years. I don't think your snide remarks are taking that into consideration. Maybe he knows more than you?
  - twic 6y ago
    Could be! But plenty of competent people have that too, so he's still ahead!
- ChrisRR 6y ago
  Yeah I genuinely don't understand it. His work is universally panned in the team, he's had multiple disciplinaries against him due to low quality work and keeps scraping through. I could never be that person, I always strive to improve and become better.
  - CaptArmchair 6y ago
    Ah. I think it's an example of how you and your employer use different frameworks to attribute value to what your co-worker brings to the table. Whereas you put focus on aspect such as maintainability, readability, adaptability, testability,... of the code he's writing, your employer might simply keep him around either because his code, well, simply "works" to a degree that is satisfactory, or because of a complex interpersonal relationships which have been established over decades turning him into much into a fixture. Put more succinctly: No one wants to know what goes into making a sausage. That is, there's little value in explaining or arguing the fine technical details of code optimization, architectural design, functional programming, etc. etc. etc. if you don't consider your audience. Stakeholders who rely on your co-worker's work simply want to know what his work could mean to them, and how it helps them get the job done. Your concerns regarding code quality are totally valid, but unless you, as the maintainer, will be fully perceived by your employer as a formal stakeholder in your own right, your objections risk being thrown in the wind. At that point, it's not just a co-worker issue, it becomes a workplace culture issue. If there's a dissonance in the manner in which he's held accountable for the quality of his work by the team on the one hand, and management on the other hand, then how does that same dissonance affect how your own work gets perceived? If he gets to scrape through, does that then imply that you're putting the bar for yourself really high, whereas you could clearly get away with doing less? Or are you trucking on despite the fact that your work is held to a different standard because there's a different expectation towards your own performance? I think striving to "improve" or "become better" is something that only means anything if you do it for yourself first and foremost. Because that's what you want for yourself. It's a valid pursuit to want that for yourself. Whereas you have to be mindful that few people selflessly care about that desire and go out of their way to let you self-actualize that. After all, your job is first and foremost a business deal between you and your employer, and the primary reason why you are there is because your employer feels there's value in what you bring to the table. If you work in a group, it's equally important to understand how to compromise on where you set the bar for yourself and others. Of course, in your case, you don't want to compromise on what you want for yourself to the point where you start to cross personal boundaries, lest you want to end up resenting the entire situation.
- zoomablemind 6y ago
  This may be an example (rather dysfunctional) of a Domain Owner. Someone, who is by historical reasons is entrusted with guardianship of the particular part of the local knowledge management. The worse the code, the more the likelihood and indeed the need for a role like this. This is clearly systemic, and is a red flag for the whole org/unit. Whether such a Domain Owner is aware of his standing - that's a philosophical question. Job security on the one hand, inertia on the other, compounded with the very much environment that gives such role more support. Just wish these guys are willing to share the crusts of the tribal knowledge with you, as this is where their true expertise may be. Side note: if there's this perceived disparity in the technical skill, the seniority in such org may trump the merit. There could be a way to get such Domain Owners on your side; pointing out their lack of skill is not the one, in fact this can backfire literally.
- caymanjim 6y ago
  I've worked with innumerable people like this over the decades. The thing is, they're usually not phoning it in. They're really trying hard. They just suck. It looks like they're working hard, because they often show up early, stay late, ask a lot of questions, and produce a lot of output. It's hard to fire them, because to many outsiders, they're workhorses. They know just enough to scrape by on each task, but they also have institutional knowledge and social connections that make them seem invaluable. Often that institutional knowledge is that they're the only person who understands their own shitty code. Their more-capable peers usually know that they're incompetent, but management doesn't. There are many reasons people like this can survive. Peers don't want to explicitly throw them under the bus. The best of their peers simply move on--to other projects in the same company, or more often, to greener pastures at another company. Their peers cover for them, because it's easier to work around a millstone like this than it is to get them removed. It takes months of concerted effort to get a peer fired for underperforming. If you want to try to get someone like this fired, it starts to look like you're the asshole with a personal vendetta. Especially because they've been there for a decade and you probably just arrived. These millstones aren't outright incompetent. On paper they've got extensive experience. Socially they're well-regarded by everyone at the company except their immediate peers who know they suck. They've been faking it and faking it well since long before you arrived, and they'll be doing it long after you've departed. Make no mistake, though. These people are rarely phoning it in. They are busting ass to tread water. Sometimes they believe their own lies, but more often they are terrified that someone will find out just how bad they are. That's why they work so hard.
  - brabel 6y ago
    It's a matter of perspective... someone, somewhere in one of your previous workplaces, might have thought of you exactly as you think of these people. So maybe don't judge too much.
  - SwiftyBug 6y ago
    Damn, that's me in 10 years. I'm so bad at my job that my only hope is that I go by unnoticed long enough so my time in the company becomes a strong reason not to fire me. It's been almost two years so far. The thing is I really try to improve, and in some ways I even do, but at a painfully slow pace. Even though I've been in this company for nearly two years I've been working as a software developer since 2012. And it hurts so much to see people coming fresh out of college outperforming me by orders of magnitude. It makes me feel really stupid. But is a really well paying job in a somewhat big company, so I hold onto the hope that if I don't screw up things too much my employers won't even acknowledge my existence. In the end I only feel bad for the people I work with (not those I work for) because they are nice and talented people and it must suck to work with someone that lowers the team's bar.
- swader999 6y ago
  A lot of these types are the first to get laid off with the best severance packages. Do this three or four times in a career and you end up with a sizable nest egg.
darkerside 6y ago
Maybe a challenging question, but did you give him feedback? IMO, that's the real way to stop people from ending up as an Expert Beginner. It's not that they need to adopt a new paradigm that they don't know about. It's that they need to know when they do something that sucks. People are amazing at self correcting of they have visibility into the problem. But when people around you enable and tolerate poor code instead of correcting it gently but firmly, you don't know what to correct.
- ChrisRR 6y ago
  Yes, he has had years of code reviews pointing out every thing he's doing wrong, every way he could improve and still refuses. Refusing to use version control is a prime example. The industry as a whole has unanimously decided that version control is necessary, but he still argues that his backup of an entire directory that he does once every 2 months is more efficient
  - ownagefool 6y ago
    He doesn't want to learn the new thing. Just refuse to accept the code unless it's a PR; leave him no choice.
    - ChrisRR 6y ago
      Already tried. I've been told to just merge it and stop being awkward
      - Lio 6y ago
        Who ever is telling you to accept that is really the one responsible. They're the one setting the standards for the team. Your colleague is just working to rule and the rules are lax.
  - u801e 6y ago
    > Refusing to use version control is a prime example. The industry as a whole has unanimously decided that version control is necessary, but he still argues that his backup of an entire directory that he does once every 2 months is more efficient For what's it's worth, a lot of people who use version control treat it as a backup system instead of as a record of logical changes to the code base with a detailed description of what has changed and why.
bluedino 6y ago
I worked at a place where the main programmer had been there 20+ years. To this day, they are still using a language which was popular in the 90's, but you rarely see today. The day I interviewed, he said "I know I'm not the best programmer but I believe that after enough hours on the project you will end up with something that works", and he bragged about many nights sleeping in the office on a cot he had under his desk, keeping systems running and debugging live programs. It was some of the ugliest code I had ever seen in my life. Every couple years, they'd hire an actual programmer, but he refused to change his methods, and the programmers would eventually find another job out of frustration. It was very easy to see which code was done by the other programmers, it just made so much more sense than his code, it was documented, etc etc.
- ChrisRR 6y ago
  Sounds similar. So many of the hours he logged were because of trying to shoehorn features into the ratsnest of code. If he had rearchitected chunks of the code into something more logical, then it would've saved time overall. I don't think he understands the purpose of architecture is to make future development easier, and instead thinks that if you make all variables global to be changed anywhere at any time, then that makes it easier and faster
- Nextgrid 6y ago
  I think there is a balance to be struck here. I definitely agree that his approach to code quality is bad and he should improve. On the other hand, he still seems to be delivering value to the business by making things work, regardless of how awful the code is, and I feel like this is still an improvement over the other extreme which is chasing hype and buzzwords while delivering near-zero actual business value.
hahamrfunnyguy 6y ago
There's a lot of developers out there like this. It's best to avoid hiring them. I think would call this person a lousy developer and not an expert beginner.
battery423 6y ago
So i introduced Code Review in our Project after i joined it. The other 2 senior people never came up with the idea of introducing it. One of them is still putting Tickets in Review which still lack basic quality expectations. My biggest / most used quality right now is persistence and pointing out the same misstakes/issues over weeks and month... And don't get me wrong, there are only two options to this: 1. Get your collegues up to speed and be persistent 2. Search for a new Team The obvious choice of not caring doesn't work for me.

BossingAround 6y ago

"If it ain't broke"... :))

ohazi 6y ago

In flying, logged hours are often used as an indicator of experience. A quip I've heard from at least two instructors: "You can fly 400 hours, or you can fly the same hour 400 times." Sounds like your coworker has had the same first year of experience 30 times...

twic 6y ago

And he's still got a job. So who's the real genius here? I don't want to be that guy, and i don't want to work with that guy, but i have to confess to a certain jealousy that people like him have figured out how to sit back and just phone it in and collect pay cheques for thirty years.

cyberdrunk 6y ago
If he has any degree of self-awareness then perhaps those 30 years were riddled with anxiety over losing the job and not being able to find another one.
- thatoneuser 6y ago
  He's had the job for 30 years. I don't think your snide remarks are taking that into consideration. Maybe he knows more than you?
- twic 6y ago
  Could be! But plenty of competent people have that too, so he's still ahead!
ChrisRR 6y ago
Yeah I genuinely don't understand it. His work is universally panned in the team, he's had multiple disciplinaries against him due to low quality work and keeps scraping through. I could never be that person, I always strive to improve and become better.
- CaptArmchair 6y ago
  Ah. I think it's an example of how you and your employer use different frameworks to attribute value to what your co-worker brings to the table. Whereas you put focus on aspect such as maintainability, readability, adaptability, testability,... of the code he's writing, your employer might simply keep him around either because his code, well, simply "works" to a degree that is satisfactory, or because of a complex interpersonal relationships which have been established over decades turning him into much into a fixture. Put more succinctly: No one wants to know what goes into making a sausage. That is, there's little value in explaining or arguing the fine technical details of code optimization, architectural design, functional programming, etc. etc. etc. if you don't consider your audience. Stakeholders who rely on your co-worker's work simply want to know what his work could mean to them, and how it helps them get the job done. Your concerns regarding code quality are totally valid, but unless you, as the maintainer, will be fully perceived by your employer as a formal stakeholder in your own right, your objections risk being thrown in the wind. At that point, it's not just a co-worker issue, it becomes a workplace culture issue. If there's a dissonance in the manner in which he's held accountable for the quality of his work by the team on the one hand, and management on the other hand, then how does that same dissonance affect how your own work gets perceived? If he gets to scrape through, does that then imply that you're putting the bar for yourself really high, whereas you could clearly get away with doing less? Or are you trucking on despite the fact that your work is held to a different standard because there's a different expectation towards your own performance? I think striving to "improve" or "become better" is something that only means anything if you do it for yourself first and foremost. Because that's what you want for yourself. It's a valid pursuit to want that for yourself. Whereas you have to be mindful that few people selflessly care about that desire and go out of their way to let you self-actualize that. After all, your job is first and foremost a business deal between you and your employer, and the primary reason why you are there is because your employer feels there's value in what you bring to the table. If you work in a group, it's equally important to understand how to compromise on where you set the bar for yourself and others. Of course, in your case, you don't want to compromise on what you want for yourself to the point where you start to cross personal boundaries, lest you want to end up resenting the entire situation.
zoomablemind 6y ago
This may be an example (rather dysfunctional) of a Domain Owner. Someone, who is by historical reasons is entrusted with guardianship of the particular part of the local knowledge management. The worse the code, the more the likelihood and indeed the need for a role like this. This is clearly systemic, and is a red flag for the whole org/unit. Whether such a Domain Owner is aware of his standing - that's a philosophical question. Job security on the one hand, inertia on the other, compounded with the very much environment that gives such role more support. Just wish these guys are willing to share the crusts of the tribal knowledge with you, as this is where their true expertise may be. Side note: if there's this perceived disparity in the technical skill, the seniority in such org may trump the merit. There could be a way to get such Domain Owners on your side; pointing out their lack of skill is not the one, in fact this can backfire literally.
caymanjim 6y ago
I've worked with innumerable people like this over the decades. The thing is, they're usually not phoning it in. They're really trying hard. They just suck. It looks like they're working hard, because they often show up early, stay late, ask a lot of questions, and produce a lot of output. It's hard to fire them, because to many outsiders, they're workhorses. They know just enough to scrape by on each task, but they also have institutional knowledge and social connections that make them seem invaluable. Often that institutional knowledge is that they're the only person who understands their own shitty code. Their more-capable peers usually know that they're incompetent, but management doesn't. There are many reasons people like this can survive. Peers don't want to explicitly throw them under the bus. The best of their peers simply move on--to other projects in the same company, or more often, to greener pastures at another company. Their peers cover for them, because it's easier to work around a millstone like this than it is to get them removed. It takes months of concerted effort to get a peer fired for underperforming. If you want to try to get someone like this fired, it starts to look like you're the asshole with a personal vendetta. Especially because they've been there for a decade and you probably just arrived. These millstones aren't outright incompetent. On paper they've got extensive experience. Socially they're well-regarded by everyone at the company except their immediate peers who know they suck. They've been faking it and faking it well since long before you arrived, and they'll be doing it long after you've departed. Make no mistake, though. These people are rarely phoning it in. They are busting ass to tread water. Sometimes they believe their own lies, but more often they are terrified that someone will find out just how bad they are. That's why they work so hard.
- brabel 6y ago
  It's a matter of perspective... someone, somewhere in one of your previous workplaces, might have thought of you exactly as you think of these people. So maybe don't judge too much.
- SwiftyBug 6y ago
  Damn, that's me in 10 years. I'm so bad at my job that my only hope is that I go by unnoticed long enough so my time in the company becomes a strong reason not to fire me. It's been almost two years so far. The thing is I really try to improve, and in some ways I even do, but at a painfully slow pace. Even though I've been in this company for nearly two years I've been working as a software developer since 2012. And it hurts so much to see people coming fresh out of college outperforming me by orders of magnitude. It makes me feel really stupid. But is a really well paying job in a somewhat big company, so I hold onto the hope that if I don't screw up things too much my employers won't even acknowledge my existence. In the end I only feel bad for the people I work with (not those I work for) because they are nice and talented people and it must suck to work with someone that lowers the team's bar.
swader999 6y ago
A lot of these types are the first to get laid off with the best severance packages. Do this three or four times in a career and you end up with a sizable nest egg.

darkerside 6y ago

Maybe a challenging question, but did you give him feedback? IMO, that's the real way to stop people from ending up as an Expert Beginner. It's not that they need to adopt a new paradigm that they don't know about. It's that they need to know when they do something that sucks. People are amazing at self correcting of they have visibility into the problem. But when people around you enable and tolerate poor code instead of correcting it gently but firmly, you don't know what to correct.

ChrisRR 6y ago
Yes, he has had years of code reviews pointing out every thing he's doing wrong, every way he could improve and still refuses. Refusing to use version control is a prime example. The industry as a whole has unanimously decided that version control is necessary, but he still argues that his backup of an entire directory that he does once every 2 months is more efficient
- ownagefool 6y ago
  He doesn't want to learn the new thing. Just refuse to accept the code unless it's a PR; leave him no choice.
  - ChrisRR 6y ago
    Already tried. I've been told to just merge it and stop being awkward
    - Lio 6y ago
      Who ever is telling you to accept that is really the one responsible. They're the one setting the standards for the team. Your colleague is just working to rule and the rules are lax.
- u801e 6y ago
  > Refusing to use version control is a prime example. The industry as a whole has unanimously decided that version control is necessary, but he still argues that his backup of an entire directory that he does once every 2 months is more efficient For what's it's worth, a lot of people who use version control treat it as a backup system instead of as a record of logical changes to the code base with a detailed description of what has changed and why.

bluedino 6y ago

I worked at a place where the main programmer had been there 20+ years. To this day, they are still using a language which was popular in the 90's, but you rarely see today. The day I interviewed, he said "I know I'm not the best programmer but I believe that after enough hours on the project you will end up with something that works", and he bragged about many nights sleeping in the office on a cot he had under his desk, keeping systems running and debugging live programs. It was some of the ugliest code I had ever seen in my life. Every couple years, they'd hire an actual programmer, but he refused to change his methods, and the programmers would eventually find another job out of frustration. It was very easy to see which code was done by the other programmers, it just made so much more sense than his code, it was documented, etc etc.

ChrisRR 6y ago
Sounds similar. So many of the hours he logged were because of trying to shoehorn features into the ratsnest of code. If he had rearchitected chunks of the code into something more logical, then it would've saved time overall. I don't think he understands the purpose of architecture is to make future development easier, and instead thinks that if you make all variables global to be changed anywhere at any time, then that makes it easier and faster
Nextgrid 6y ago
I think there is a balance to be struck here. I definitely agree that his approach to code quality is bad and he should improve. On the other hand, he still seems to be delivering value to the business by making things work, regardless of how awful the code is, and I feel like this is still an improvement over the other extreme which is chasing hype and buzzwords while delivering near-zero actual business value.

hahamrfunnyguy 6y ago

There's a lot of developers out there like this. It's best to avoid hiring them. I think would call this person a lousy developer and not an expert beginner.

battery423 6y ago

So i introduced Code Review in our Project after i joined it. The other 2 senior people never came up with the idea of introducing it. One of them is still putting Tickets in Review which still lack basic quality expectations. My biggest / most used quality right now is persistence and pointing out the same misstakes/issues over weeks and month... And don't get me wrong, there are only two options to this: 1. Get your collegues up to speed and be persistent 2. Search for a new Team The obvious choice of not caring doesn't work for me.