Drunk Post: Things I've Learned as a Sr Engineer • Hacker News Board

Re: Drunk Post: Things I've Learned as a Sr Engineer

#121

Post by catlifeonmars » Sun, May 30, 2021, 5:23 PM UTC

palijer wrote: post #110

dataflow wrote: post #87

Earlier quoted context omitted.

I disagree strongly with it on multiple fronts. That concern should be secondary to your program actually doing its job well. Your customer will literally not care how elegant or ugly your code is; they just see the end result. And when the program fails them, it really doesn't matter to them whether your juniors understand the code or the error. Moreover, not every abstraction is (or can be expected to be) accessibl…

It really does matter to the customer if the junior understands it when the code fails though. Easy to understand code can be more quickly patched and repaired by anyone on the team. If you don't need to call in the senior who built it two years ago to repair it, and you can have someone do it right away, it is better for the customer.

Assuming that senior is still working there.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#122

Post by derekja » Sun, May 30, 2021, 5:27 PM UTC

MikeDelta wrote: post #105

actinium226 wrote: post #86

Earlier quoted context omitted.

I agree with having empathy for future devs, but I think it only goes so far. I've often seen junior engineers unable to differentiate between code they don't understand and bad code. Usually they end up thinking they can do a better job, decide to rewrite the thing from scratch, and take 10x longer to rewrite it than they thought it would take. And accomplish nothing in the end, because the thing they rewrote worked…

Indeed, and during rewriting they realize why the original code was made that way and how it solves the problem more efficiently than their rewrite.

if they get to that point I’d say it was worth their time!

Re: Drunk Post: Things I've Learned as a Sr Engineer

#123

Post by whymauri » Sun, May 30, 2021, 5:28 PM UTC

Philip-J-Fry wrote: post #79

EMM_386 wrote: post #6

> I don't know why full stack webdevs are paid so poorly. No really, they should be paid like half a mil a year just base salary. Fuck they have to understand both front end AND back end AND how different browsers work AND networking AND databases AND caching AND differences between web and mobile AND omg what the fuck there's another framework out there that companies want to use? Seriously, why are webdevs paid so…

I see where you're coming from, I do all that too. But it's the "jack of all trades" thing. You "know" all that, but do you actually __know__ all that. I can develop a nice relational database design, write the SQL stored procedures to manipulate it, write a backend API and write the front end SPA for it. I don't think I'm an expert in any of those things though, and if I am then it's more focused on the backend API…

>You "know" all that, but do you actually __know__ all that.

Companies that underpay fullstack web developers usually don't actually care if their engineers __know__ all that, either. They just want the cheapest, fastest, CRUD app they can demo and ship out ASAP. As a result, these employers fail to recognize (and reward!) the fullstack web developers who do actually __know__ the full stack.

At my last job there was a rockstar web developer engineer who could easily double their compensation by moving to a larger company instead of a startup. My advocacy for them to get a raise or promotion was cast as 'the engineer is complaining again."

Re: Drunk Post: Things I've Learned as a Sr Engineer

#124

Post by GordonS » Sun, May 30, 2021, 5:29 PM UTC

ChrisMarshallNY wrote: post #11

vageli wrote: post #3

> The most underrated skill to learn as an engineer is how to document. Fuck, someone please teach me how to write good documentation. Seriously, if there's any recommendations, I'd seriously pay for a course (like probably a lot of money, maybe 1k for a course if it guaranteed that I could write good docs.) I agree but think it is more than just _documentation_: effectively communicating ideas through text was one o…

I just use headerdoc-type stuff. Been doing it for decades. It works very well, and doesn't really add any overhead to my work. I write about how I do documentation here: https://littlegreenviper.com/miscellany/leaving-a-legacy/ It's a long read, because it's a big topic.

That's useful, but only covers documenting the code, and API usage.

Depending on the project, various other documents may be required, e.g. installation guide, user guide, operations manual, architecture diagrams, networking diagrams, module/component diagrams, information flow diagrams, high-level design, low-level design, docs at various "views" (such as "business view", "information view", "technology view"), design decision tracker, ontology...

Re: Drunk Post: Things I've Learned as a Sr Engineer

#125

Post by andai » Sun, May 30, 2021, 5:29 PM UTC

daenz wrote: post #22

eqmvii wrote: post #5

> 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…

Sounds like the style in which most Wikipedia articles are written.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#126

Post by redisman » Sun, May 30, 2021, 5:30 PM UTC

runawaybottle wrote: post #21

aszen wrote: post #7

Earlier quoted context omitted.

I think people in the industry are paid based on the potential value they can create (whether real or not), knowing many things or understanding fancy technologies matters little if one can't put them to use for the benefit of the company.

Also, most companies like to brand themselves as ‘tech’ to signal that they are growth based. Why is Peloton a tech company? They’re not. A lot of us have jobs because companies need to fulfill the image. It’s half the reason why so many people are allowed to do full-stack when in reality they would have no business dealing with those parts of the stack in a real operation. So no, you don’t actually deserve more mone…

Isn't their core product some kind of a streaming service that you pay for monthly?

Re: Drunk Post: Things I've Learned as a Sr Engineer

#127

Post by catlifeonmars » Sun, May 30, 2021, 5:30 PM UTC

mgfist wrote: post #95

andy_ppp wrote: post #93

Earlier quoted context omitted.

This assumes you are absolutely certain you know what the code should do. And that it does what you think it does. Hence while you might think “performs its task” is an easily defined I’d disagree. I’d take clear code that wasn’t working over code that was hard to reason about and somehow worked every day.

> 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.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#128

Post by vsareto » Sun, May 30, 2021, 5:31 PM UTC

>I don't know why full stack webdevs are paid so poorly. No really, they should be paid like half a mil a year just base salary. Fuck they have to understand both front end AND back end AND how different browsers work AND networking AND databases AND caching AND differences between web and mobile AND omg what the fuck there's another framework out there that companies want to use? Seriously, why are webdevs paid so little.

Full stack compresses two jobs into one. It's purely for cost-savings. They're paid so little because companies revert to "well, you can still only do 8 hours, so you do half as much of each", but really that's just them trying to weasel out of paying for knowledge. They also blur the lines by putting full stack along-side other devs, even though the other devs may not have invested the same time to gain as much knowledge as full stack.

When you take a full stack job, you undervalue your knowledge (and the time invested) and are selling it for roughly half of what it's worth.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#129

Post by swader999 » Sun, May 30, 2021, 5:31 PM UTC

mikepurvis wrote: post #119

fighterpilot wrote: post #117

Earlier quoted context omitted.

Can you elaborate on what you mean by a boundary? You mean logging the interface between two services or modules?

Boundaries between anything . I recently was dealing with an issue in a Jenkins pipeline, where I didn't realise that state was being serialized to string form between job stages until I explicitly logged it out. The thing that was a list in the previous stage was suddenly a string, but then Groovy would happily accept the join method on a string because it's still an iterable. Auuugh.

Both these above are great answers. It's a bit of an art.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#130

Post by dijit » Sun, May 30, 2021, 5:31 PM UTC

Tempest1981 wrote: post #16

vageli wrote: post #3

> The most underrated skill to learn as an engineer is how to document. Fuck, someone please teach me how to write good documentation. Seriously, if there's any recommendations, I'd seriously pay for a course (like probably a lot of money, maybe 1k for a course if it guaranteed that I could write good docs.) I agree but think it is more than just _documentation_: effectively communicating ideas through text was one o…

I've seen lack-of-documentation worn as a badge of honor. "I'm moving so fast, I can't waste my time on documentation. That's the next guys problem." And management is usually/always ok with this short-term optimization.

But there are circumstances where documentation would be outdated before it is finished.

Trying to write ops documentation on an unfinished project can be this way.