Earlier quoted context omitted.
> I’d take clear code that wasn’t working over code that was hard to reason about and somehow worked every day. Then you'd be out of business.
I look at it this way: Most likely the code I write has a bug in it. Or, at the time of writing, the customer requirement is fuzzy. Or, I have a limited grasp of the problem domain. Even if it is not any of the above, most likely there will be a change in a business requirement that impacts the code. So whenever possible, I opt to write code that is either stupidly obvious, trivially testable, or easily replaceable.
Drunk Post: Things I've Learned as a Sr Engineer
131–140 of 510 posts
Re: Drunk Post: Things I've Learned as a Sr Engineer
#132This got me and somehow bloody true.
Re: Drunk Post: Things I've Learned as a Sr Engineer
#133Earlier quoted context omitted.
I don't know. Possibly it's simply because when you accept a career in the thing you're passionate about the thing you're passionate about becomes work. Another thought that has occurred to me of late: when I started in this field it was "Computers" (capital "C") — a thing really by nerds, for nerds. Increasingly it's the web, mobile. Our "customers" are increasingly not us and so the decisions that would have come s…
Yeah, I don't think there's anything special about working in tech. I've seen the same exact dynamic happen in lots of other fields. People who love cooking and become professional chefs only to leave after a few years is extremely common, for instance. So much so that I would have said it is pretty common advice that if you try to turn a hobby you love into a job, there's a good chance you'll end up losing your pass…
Re: Drunk Post: Things I've Learned as a Sr Engineer
#134>Don't meet your heroes. I paid 5k to take a course by one of my heroes. He's a brilliant man, but at the end of it I realized that he's making it up as he goes along like the rest of us. I thought they were going to go the direction of "he's an asshole" and was ready to accept that, but this particular criticism is actually disturbing. People with strong visions can often appear to be "making it up as they go along,…
(I work at Red Hat, and my programming heroes are also my colleagues.)
Re: Drunk Post: Things I've Learned as a Sr Engineer
#135> Good code is code that can be understood by a junior engineer. Great code can be understood by a first year CS freshman. The best code is no code at all. This a thousand times. Having empathy for future devs, maintenance, and bug fixes is so important.
Amen. Something bizarre I have noticed though in junior-almost-senior engineers is that they pride themselves in obfuscating and writing "highly complex" logic, with no documentation. It's almost like they are demonstrating their new abilities in the worst way possible. I have been dealing with one of these engineers recently, and they have expressed to me that they love writing because it's so terse. It's been a poi…
Re: Drunk Post: Things I've Learned as a Sr Engineer
#136This, and the current “sober” posts on r/ExperiencedDevs, makes me think of Herodotus describing the way the Persians made important decisions - once sober, once drunk, and if the drunk and sober decisions were the same they knew it was a good one.
https://en.wikipedia.org/wiki/In_vino_veritas Is the phrase. Useful if you want to appear cultured at a company party.
Re: Drunk Post: Things I've Learned as a Sr Engineer
#137> Good code is code that can be understood by a junior engineer. Great code can be understood by a first year CS freshman. The best code is no code at all. This a thousand times. Having empathy for future devs, maintenance, and bug fixes is so important.
I am not saying the code cannot be made better or more clear. But, it also depends on who you are writing to. Somebody who is not familiar with certain style of programming cannot easily read the code of certain level of complexity.
When I was hacking away my first big program, I could not write functions. Or find reading functions easy. The whole thing was a big wall of glorified assembly sewn together by labels. I am not sure why I was like that then, but I found concepts 'functions' and recursion or any other conceptual stuff really hard. My code was, in its own twisted way, 'most simple' and utterly unreadable.
I find the same sort of difficulties while reading some FP snippets. I confess it was a very short affair, but I had some difficulty reading it and even when I understood, I could not just write or think code in the same style.
There are ways to make your code better, your intentions clear but 'can be understood by a first year CS freshman' is bit abstract criterion.
It is kind of like, vocabulary and prose. You can make your prose clear. But, people have to work on the vocabulary on their own.
> The best code is no code at all.
This is completely agreeable.
Edit : Changed some poor word choices. Added an analogy.
Re: Drunk Post: Things I've Learned as a Sr Engineer
#138Earlier quoted context omitted.
Antescriptum is probably the closest to the root of the word “pro-gram”.
That's a good find, but I was unsure of whether "program" is semantically equivalent to "code" here. Plus I'm tempted to leave codex since it sounds so good.
Re: Drunk Post: Things I've Learned as a Sr Engineer
#139Probably people are honest when they are drunk. There is nothing to argue with any of those comments. But this one stood out for me! > Titles mostly don't matter. Principal Distinguished Staff Lead Engineer from Whatever Company, whatever. What did you do and what did you accomplish. That's all people care about.
That's true unless you get acquired. At that point, your title is what your new overlords will use to determine your role, salary, and even whether to lay you off.
To say nothing of a lot of brain.
Re: Drunk Post: Things I've Learned as a Sr Engineer
#140> If I'm awaken at 2am from being on-call for more than once per quarter, then something is seriously wrong and I will either fix it or quit. Sometimes fixing the problem will require special access to Production which you don't have, or even a specific role with that extra bit of initiative. Otherwise i agree 100%.
If it's unfixable, that's when you quit