Being a good coder is like 30% of your job. The rest is being a good teammate, which is about diplomacy and communication.
My favourite co-workers today and in the past would almost certainly never get a FANG interview but damn do they have the passion to do well and work together.
Just my experience.
I think good programming is how much wtf/ minute you have, when you read the source.
I'm normally easy to talk to, but I'm having difficulty for that now because:
- fixing a simple bug leads to a rabbit hole of fixing bugs.
- no seperation. Something can influence something everywhere. It's nuts, eg. A text explanation on a enum ( state) has been added in the businesslayer and transformed 3 times before it reaches the frontend. ( I removed all those texts to show only on the view with the appropriate conditionals)
- code is unreadable -> too much time spend in debugging
- a bug was fixed when it did something wrong, instead of looking for the root of the problem. So actually fixing a bug correctly creates a new bug, because it has already been fixed 2 times on different places. Just the root case was never fixed before.
- ...
All in all, solving a bug is tedious. Fixing it the right way, creates so much bugs, because previous workarounds for probably the same/similar bug everywhere around.
I'm pretty sure that good programming leads to better communication.
And bad programming leads to a clusterfuck of problems
[0]: https://www.amazon.com/Working-Effectively-Legacy-Michael-Fe...
oh my god! this is so much me it is not even funny
Sometimes I'll take a little short-cut, because an innocuous little hack that adds a constraint or assumption seems like better value than going the long way round. Sometimes the design changes as you figure out new ways the product can/should work to be cooler, and old abstractions are no longer useful, or new abstractions become useful, or data that lives over here now needs to get aaaallll the way over there, God Dammit. All abstractions leak, and the first design is never right.
And maybe it's fine, because I wrote it all and I can rewrite it quickly enough, but in the real world we can't just go and rip up that code because we don't have the muscle-memory for it, and because of Chesterton's fence.
Maybe good code is code that can be deleted easily, or rewritten without fear. Maybe it is code that has been rewritten enough or has survived long enough to embody some kind of wisdom. I know that it is simple, and that it makes the life of its user simpler.
And today I encounter the actual article where this originated from. This bit is iconic.
this got me Lol’ing pretty loud
In my experience, most problems and frustration comes from working the APIs (or somebody else's interpretation of the business need) -- not programming language.
This is pure comedy gold, thanks!
It gets me through the day. When management asks something nonsensical, or I'm forced to push a hack to prod to fix things.
> Composed on the 27th of April in the year 2014
5 years later, and it still sucks.
Stick to the plan Stan. Even when it could be better steven.
