Advice for a senior level developer who makes lots of mistakes

My reaction time is about 20-30% faster than my teenage son. I beat him at chess consistently even though I inevitably make one or two boneheaded mistake(s) early on but I have a good understanding how to open up and control the space I keep the pressure on relentlessly.

People have always told me not to sweat it about the mistakes that I make and that the fear of the mistakes is just going to cause more mistakes and maybe they are right.

In software I know I do exceptionally well at figuring out things like "where do I pull down data in this React application so that it can flow to all the places it needs to go" and it drives me up the wall that most people go about that kind of thing randomly and wonder why the layout is jumping up and down all the time but don't seem concerned that the render() method gets called 15 times when it only ought to get called once. Despite that, my boss catches an occasional howler of mine during a code review but that's why he does a code review.

I am in the process of rewriting my own internal "software" for interacting with people and I wouldn't know how to explain it or what I am doing except that I read a biography of Benjamin Disraeli and learn from it or watch an episode of Quantum Leap and see it as "performing arts about the performing arts" as opposed to science fiction.

https://fs.blog/2020/03/chestertons-fence/

There will be many things that don't make sense or look wrong initially. Its possible that they *are* wrong, and you can improve on them. The key to productivity is being able to demonstrate that your prospective changes don't break anything, and do in fact improve things.

I doubt people are "withholding information" from you, probably the people who made the decisions left, or are busy with other things now (management). It's your job to gather the information you need with what you have. It may be the case that you need to invest heavily in testing, logging, instrumentation and debugging skills on the current system to understand how and why it works as it is, and whether your changes make things better or worse.

Many developers never get past a composition first mindset. That is beginner shit. It’s putting legos together without the instruction manual only to stress about how the pieces click together instead what the final state is. You end up with lots of decoration and shit everywhere. In the military we call this not seeing the forest for the trees.

As a senior myself in the corporate world who enjoys writing open source software there is a world of difference between people build products and people that just write code at work. It’s a difference in velocity, planning, and volume. When you are writing software on your own where you aren’t paid for your time you tend to be in far less of a hurry and yet produce 10x as much. As a corporate developer you are paid to hurry and complete tasks and in many cases with incomplete documentation, which is just writing code and sometimes guessing at what you need. When you are on your own success is measured in product delivery and feature completion, which is not just writing code.

Another major difference is communication. If you communicate poorly your open source software is dead on arrival. End of story. You should never have to guess at your business requirements, APIs, steps to reproduce defects, and various other things. The more you have to guess the more mistakes you will make. The only path to redemption is to communicate more precisely than those around you.

Perhaps the worst distinction is design by committee. Frequent long meetings just waste peoples time. The time that’s left over means hurry harder. A more productive direction is for some fool to sit a position of leadership and make arbitrary decisions. A wrong decision can be fixed, but wasted time is gone forever.

You can’t really explain this to a developer who has never written code outside the office because they refuse to believe what they have never experienced. The hurried low productivity churn is all they know.

When I was forced to in order to correct my mistake I realized that reading the code would have been so much easier to begin with, and even exciting… kind of like a puzzle to be solved.

Trying to understand a project, starting with main, arguments, env variables all the way down to the part your are interested in gives SO MUCH insight not only into the project but into the company and their process.

Code don’t lie. It’s a hurdle to get past but understanding the project as a whole give so much insight (i. e. edge cases, hacks used in the past, etc.) and confidence when fixing a specific problem.

I have the same problems and get into rabbit holes quickly.

After some research on the internet and in my past life (got fired twice this year /o\), I concluded to do a ADHD/ADD assessment. I got Diagnosed with ADHD.

The main thing that changed: I’m more aware of the mistakes I do and notice my behaviors early on and can mitigate the bad parts.

So for me the answere is simply: maybe try todo some online ADHD test and if it indicates a potential diagnosis, do a real one with a psychiatrist.

For example caching has burned me so many times that when I see an application doing caching I will triple check my solution because it might look good because it's the cache looking good, not your change, or vice versa.

In my opinion there are two approaches you can take.

Approach 1 - Wrecking Ball: Implement entire solution using dirty code. The point is to have the solution "working" and handling in the most likely use case. Then you start adjusting your code, abstracting, handling edge cases, dealing with error handling etc. This is like a depth first approach

Approach 2 - Radar: Implement the solution in layers. Like a radar scanner that goes from a center point out. You add code in layers, so first you get the inputs you need, then you do calcs, then work on errors. The key is test each layer, this is where unit tests become invaluable. This is a breadth first approach.

I am not a huge fan of pure Test Driven Development, but a hacky approach works well. I like writing code then testing. Now the test might be an automated test, or print statements, sometimes even visual.

Both approaches require a double check of what you have done. I am more of an approach #2 person. Mainly because my mind works like a weird neural network, I go depth then pull back and explore parallel avenues determining the best way to get to my target. Anyway, I digress.

The point I am trying to make is that regardless of your approach you have to test. Don't get stuck with test = unit test, but testing frequently and early is key. This can help with "2 days troubleshooting an error that you caused yourself"

The other hurdle you have is you are working on an existing project that you don't have experience in. The tribal knowledge is what gets you. Are you familiar with Cunningham's Law? To paraphrase, the fastest way to get an answer to a question is to post the wrong answer. Now something I have noticed is that if it's a Code Review, some people will just rubber stamp it, so they won't catch your errors and it will boomerang back to you. So I abuse human psychology instead. Mainly that people will pay attention if you use their names and ask for help.

It works even better for natural pessimists, but what I do is describe my code in words. Let's mock this...I'm going to use Groovy, mainly because I was Code Reviewing this change the other day.

    def calculateDuration(start, end) {
       long elapsedTime = end - start

       Long second = (elapsedTime / 1000).longValue() % 60
       Long minute = (elapsedTime / (1000 * 60)).longValue() % 60
       Long hour = (elapsedTime / (1000 * 60 * 60)).longValue() % 24
       Long remainderMillis = elapsedTime % 1000

       return "${hour}h ${minute}m ${second}s ${remainderMillis}ms"
    }

Hey XYZ, I need your help.

I am writing some code to easily be able to calculate the duration of things. I assume milliseconds as input, and a start and end time will get passed in.

Then I use that time to do an 'end - start' and figure out how many hours, minutes, seconds and milliseconds based on that result returning it as an "Xh Ym Zs Kms" string.

Anything I might have missed? Can you think of any edge cases that I might know about?

Thanks,

-----

Then if the discussion progresses I will point them to my specific branch. Programmatically we could debate the use of Long vs long. Or typing the input parameters and return or not.

The thing is this "solution" missed a key aspect. Milliseconds can't be assumed as input. He had tests, but all his tests were using milliseconds. If I had rubber stamped it as a code change, within three days we would have started getting messages from POs, and they would show up in Kubernetes namespace metadata, which if you don't know how things connect to each other, it would be hard to figure out why the metadata in a pod suddenly changed.