Totally sucks. Code reviews and factual evidence of production maintenance concerns might help. (Mgmt is likely to dismiss concerns as whining unless there is clear evidence of a problem.)
Can you change the variable names and throw some of the sanitized insanity into a gist?
In a small shop, a single person can easily be a huge liability. There's usually nowhere to hide because everyone has to be delivering on overall execution. If cofounders are from enterprise, this might've been lost in translation.
if(a == false){
b = true
}
if(b == true){
a = false
}
Then you use either b or a in the code, depending on your feeling of the day.
ANother great example, is inter thread communication, being performed using a boolean in database.
The boolean is checked using a while true loop, in each process.
The database was hit several thousand times a second, by each thread.
In the end, it appears that the variable is just a shared value.
Based on the boolean example, I'm curious whether he was purposely writing bad code, just to mess with you. He may have really not cared for his job or been out to be purposely malicious for some other reason.
Makes me wonder. Has this ever person built anything themselves that scaled? Because at this rate, the database is going to be an even bigger bottleneck that it usually is.
There are plenty of people with decades of bad habits because there wasn't code review, peer coaching or treating coding as a "magical" [0] artisan profession. Something to be constantly refined but never completely mastered.
> Question: How does a large software project get to be one year late? Answer: One day at a time!
12000-thousand-line-long methods do not appear out of nowhere and in one go; rather, it gradually acquires cruft. To combat this, introduce peer review: code review by sending a patch to an internal mailing list, merge/pull requests in GitHub/BitBucket/GitLab/Stash, feature branches, etc.
I fully agree with that.
Our bigger mistake, being such a small team, was to let the guy fully in charge of the project for so long.
But the conditions were also kinda special.
I was the junior, with him having close to 15 years of experience.
We were only 2 in the office. The rest of the team being in another country.
So I was basically the only one to see the code. And he would listen to me, being the junior.
So I requested not to work anymore, not being able to bear the situation.
Best advice might be to double-down on putting everything you're doing in the issue tracker and tying to commits. Don't get lumped into the "problem" when "why aren't we executing?" gets raised. Focus, ship & get credit for your work that gets shit done.
I wouldn't worry about other damage he'll inflict... If a company has so little oversight that no second pair of eyes is reviewing his work, then it deserves to fail. Yes, as you have acknowledged, what happened is as much your fault as his. Bad apples do make their way into every organization, and oversight must exist.
In any competent company that he gets a job next, he'll quickly be fired or reprimanded if he writes 12,000 line long methods. There doesn't need to be any further oversight than the standard industry oversights that already exist internally at companies.
14 comments
[ 1.6 ms ] story [ 53.1 ms ] threadCan you change the variable names and throw some of the sanitized insanity into a gist?
I mean there is stuff so bad that even my non programmer friend laughed at.
But naming the guy, or putting the guy's name out there would be a fault from my side, which I don't want to make :).
But I really do see frightening stuff, trust me :).
In a small shop, a single person can easily be a huge liability. There's usually nowhere to hide because everyone has to be delivering on overall execution. If cofounders are from enterprise, this might've been lost in translation.
But my point if not so much about this guy and the problems we had.
My question is more : What could / should be done to avoid this kind of developers to do more harm in other companies.
boolean a = true; boolean b = true;
And every where through the code :
if(a == false){ b = true } if(b == true){ a = false }
Then you use either b or a in the code, depending on your feeling of the day.
ANother great example, is inter thread communication, being performed using a boolean in database. The boolean is checked using a while true loop, in each process. The database was hit several thousand times a second, by each thread. In the end, it appears that the variable is just a shared value.
There are plenty of people with decades of bad habits because there wasn't code review, peer coaching or treating coding as a "magical" [0] artisan profession. Something to be constantly refined but never completely mastered.
[0] SICP, of course.
> Question: How does a large software project get to be one year late? Answer: One day at a time!
12000-thousand-line-long methods do not appear out of nowhere and in one go; rather, it gradually acquires cruft. To combat this, introduce peer review: code review by sending a patch to an internal mailing list, merge/pull requests in GitHub/BitBucket/GitLab/Stash, feature branches, etc.
But the conditions were also kinda special. I was the junior, with him having close to 15 years of experience. We were only 2 in the office. The rest of the team being in another country.
So I was basically the only one to see the code. And he would listen to me, being the junior. So I requested not to work anymore, not being able to bear the situation.
In the end, he worked alone :S
>.<
Best advice might be to double-down on putting everything you're doing in the issue tracker and tying to commits. Don't get lumped into the "problem" when "why aren't we executing?" gets raised. Focus, ship & get credit for your work that gets shit done.
Help bad developers become good developers through peer-review, mentoring, internal workshop, and so on.
In any competent company that he gets a job next, he'll quickly be fired or reprimanded if he writes 12,000 line long methods. There doesn't need to be any further oversight than the standard industry oversights that already exist internally at companies.
What happens I think is other developers just try to get away from it. Which doesn't equal to being fired
Saying it hurts...