I’m a Bad Developer, That’s the Only Reasonable Explanation

But he had one quality that I really appreciated as a lead: he persisted in what he was doing until he got it done, and without complaining or needing any prodding. So I actually did not mind much at all that he was slow, because I could "fire and forget" him at something that was important but not urgent.

In fact, the main problem I had with him, was that sometimes he would get really angry about some code or a bug, and slam his fist on the desk and/or swear. I mentioned it but you know how code is, when you're really engaged with it, the process can be emotional, and it was hard for him to temper those impulses. It was never really bad, although I was aware that not everyone wanted to pair with him. Which was fine, we generally worked around it, but when allocating tasks, he sometimes got the short end of the stick because of it.

Everyone wants their employees to be the trifecta of talented, hard-working, and nice to work with. But most employees are missing one of those traits, and some are missing two. You sound like a diligent worker but maybe not a genius. That really should be okay for both you and them, and if your manager is good he will appreciate that. But consider, are you nice to work with? If you have a choice, maybe spend your effort that way, instead of worrying that you're not talented (enough).

I hate that I work at a big company and we get into new project discovery mode and then take 3-5 weeks to code up extremely over complicated prototype programs. But they have tests (usually more than code), they have "good design", they have code that's reviewed and sent back at least thrice, they're stable, they've got monitoring, ... And they take huge amounts of time.

The one quality all of that has is that everybody agrees it's a good idea. When trying to quantify what that means ... I completely fail.

The design always fails to account for something. I have had it happen once that the initial design actually lasted to "v1.0", in 3 years. So I'm becoming unsure what makes a design good, except everyone agreeing that it's good and a certain "clean" look there is no difference between a good and bad, clean and messy, thought through and ad-hoc. Good designs don't survive a few feature iterations any better than bad designs, but they impose lots of extra costs on feature iterations. And that's assuming people don't make the mistake that turns the best of good designs into horrible designs : sticking to it. Attempting to fit new features into a design that didn't account for them can make the most beautiful design an utter disaster.

Same thing about reviews. Reviews seem to make people make huge changes in one go, because that feels much better if people regularly argue about much of it, compared to having to redo a change that by the time it's reviewed 5 other things depend on, where you get to throw out the 5 other things. And of course fairly commenting on huge changes is not done because pretty soon you'll feel guilty about the amount of work you're causing. Which is exactly why people have a better experience making huge changes, of course.

Tests ... never prevent bugs. Now I'm not saying tests don't have value, but the current testing culture is utterly and completely broken. I've simply decided to hack the system : a cli to your methods that allow you to quickly do ad-hoc tests and record them into generated code. Why ? First, it allows you to test against real-world data, which means your idea of what your code does actually meets real world data instead of artificial cases that may miss the point in the same way your code does. Second it allows you to quickly regenerate the tests if there is some big change needed. And thirdly it completely hacks the system. Getting coverage is trivial. And your LOC stats will be through the roof. Double bonus if you do this for less-than-expressive languages like C and Go, it's less necessary for things like Java and C++.

But "best practices" seem to make everyone happy in big companies, make everything take very long, and because of that very often cause the failure they're trying to prevent. It's like in chess : people like "safe" moves once you've beaten them once or twice. And in 10 moves or so they get themselves into a situation where they have to give up that safety, and your "haphazard" moves turns out control 80% of the board and fighting from that situation is not going to go well. But it's the desire for safety, the fear of loss, that's exactly what's causing their loss. They don't see things this way, though. If only they'd moved this piece to cover that as well, then it would have been fine. It doesn't even seem to matter if you show them that no, it wouldn't have been fine. That the issue was their attempt at securing what they did resulted in a complete takeover by the other party.

And every attempt I make at changing this fails, often with people having emotional breakdowns and complaints. And then their projects fail, again and again. Multiple times people have been very angry at me for providing a solution to some problem they were doing a 2 year project, restarted from scratch 3 times, for by writing a 300 line script that utterly kills interest in their project because it works and solves the problem. Apparently that "violates trust".

I don't understand why businesses want this. It keeps the peace, yes, practices like this, at the cost of efficiency, at the cost of developer sanity (developers wash out after about 5 years despite the current employment conditions, and often become non-developers. Hell, several people I know became accountants and prefer it over software development. Seriously).

And despite this, people seem to further down the rabbit hole every time I seem to look at it. WTF ?

I'm not sure if I'm humble. I sure as hell am not when I'm interviewing but I blame that on American culture.

Thanks for the feedback! :)

God, I love Seinfeld so I feel a little flattered by that! :)

The article is more of a musing about an insecurity than anything else. But as to the content, maybe I can explain a few things better:

1. The management WAS bad. The job where I was time-tracked was a nightmare in so many different ways. However, it instilled a sense of insecurity in me. A single comment from a manager at a completely different company brought all that stuff back up and ever since then, I haven't been able to put my mind to rest about my own performance.

2. Developers are often quick to blame management for problems without considering that THEY might be the problem. So I mentioned that when someone tells me "The management is bad if you're missing deadlines", it doesn't make sense to me as a blanket statement.

3. I concluded with saying that I have certain abilities that I recognize as good but I'm still wondering if that's enough or anywhere near enough.

Thanks for the feedback though! I'm trying to do better with writing this type of stuff so that it's as concise and self-explanatory as possible. Looks like I still have more work to do.

Turned out he wanted to be the boss —that was made official 2 months after my arrival. On my very first week, he started to make disparaging comments under the guise of joke (or were those real jokes?). Those soon occurred daily. Sometimes in front of the client, who (surprise!) eventually lost trust in me.

If this was my only experience, I would have thought it was me. But I have since received enough external validation about my skills (people looking up to me, actual results…) to know better. For some reason, the guy could not stand me, so he got rid of me. Another small detail: he never smiled at me in the morning when we shook hands to say hello. He did smile at everyone else.