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

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

#401

Post by robocat » Mon, May 31, 2021, 3:20 AM UTC

robocat wrote: post #313

ridethebike wrote: post #286

>> Third party recruiters are leeches Can confirm this and it was surprise for me when I discovered it. I assumed they would try to maximize $$ in my offer in order to maximize their profit. Yet most of them were trying to get offer accepted as quick as possible. Seems like more offers with less money in each is preferred over less offers with more money in each.

The same dynamic occurs with real estate agents. A successful agent optimises for quick sales, while giving the appearance of trying to get the best price. Very important to know when dealing with agents if either selling or buying a home.

To be more explicit: as a buyer, especially in a tight market, the seller’s agent will often do things or reveal information to the buyers benefit (against the interests of the seller they are supposed to represent).

There are “rules” to how the game is played, and how the information is revealed, and a lot of it seems hidden (in fact I have seen agents that don’t understand the perverse incentives!). A seller’s agent will usually need to make sure they have deniability, and they will prefer options where the vendor remains happy (so the vendor will use them again, and recommend the agent to other sellers).

I have only a very little experience, and none in the USA, but that was what I noticed in my own country.

It surprises me how little effort people put into understanding the game, given that playing it well can easily make the same difference as many years of income.

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

#402

Post by lostcolony » Mon, May 31, 2021, 3:26 AM UTC

OminousWeapons wrote: post #268

> If people are trying to assign blame to a bug or outage, it's time to move on. This is one of my favorite excerpts. I once worked in a lab where we would have frequent catastrophic failures because there was never any disaster planning or contingency management plan. I personally triaged 3 such incidents alone or with people who happened to be there when the problem arose and attempted to disseminate some suggestio…

Maybe. I've seen the opposite, where no one takes responsibility for anything, and it's also bad. In fact, the situation you describe could also be a lack of anyone else taking responsibility for disaster planning and etc.

I think what is needed is a culture of -ownership-. That's basically people saying "I'm responsible". Not one where everyone tries to avoid responsibility, and not one where peopel point fingers.

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

#403

Post by thethethethe » Mon, May 31, 2021, 3:37 AM UTC

lostcolony wrote: post #402

OminousWeapons wrote: post #268

> If people are trying to assign blame to a bug or outage, it's time to move on. This is one of my favorite excerpts. I once worked in a lab where we would have frequent catastrophic failures because there was never any disaster planning or contingency management plan. I personally triaged 3 such incidents alone or with people who happened to be there when the problem arose and attempted to disseminate some suggestio…

Maybe. I've seen the opposite, where no one takes responsibility for anything, and it's also bad. In fact, the situation you describe could also be a lack of anyone else taking responsibility for disaster planning and etc. I think what is needed is a culture of -ownership-. That's basically people saying "I'm responsible". Not one where everyone tries to avoid responsibility, and not one where peopel point fingers.

Why does someone need to take responsibility when you can have a culture of blameless postmortems where everyone focuses on making sure what ever happened never happens again instead? In blameless postmortem culture, everyone is responsible by default

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

#404

Post by Rapzid » Mon, May 31, 2021, 3:37 AM UTC

sidlls wrote: post #356

ng12 wrote: post #211

Earlier quoted context omitted.

I would say then that your project is simple enough that an underpaid full-stack dev is exactly what you want.

Possibly, but my experience is that front-end dev specialists tend to over-complicate things (usually so they can tinker with some new javascript flavored garbage).

My experience is that a lot of engineers do this regardless of where they work in the stack..

It can actually be important too for learning, moral, and innovation. Keeping it from negatively impacting the project is the trick.

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

#405

Post by staysaasy » Mon, May 31, 2021, 3:39 AM UTC

daenz wrote: post #18

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

IME most people will generally appear to be making things up as they go – even if they have significant relevant experience. Every situation is unique, and experience tends to look more like having a list of techniques with varying degrees of expertise, rather than having a playbook for every situation. You have to look for the expertise rather than raw confidence.

In sports terms it would be something like a baseball pitcher being able to throw a great curveball, a great fastball, and an all right slider, and knowing roughly what situations to use them in. There will still be a high degree of randomness and mistakes will be made.

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

#406

Post by kbenson » Mon, May 31, 2021, 3:40 AM UTC

lazyant wrote: post #367

OminousWeapons wrote: post #268

> If people are trying to assign blame to a bug or outage, it's time to move on. This is one of my favorite excerpts. I once worked in a lab where we would have frequent catastrophic failures because there was never any disaster planning or contingency management plan. I personally triaged 3 such incidents alone or with people who happened to be there when the problem arose and attempted to disseminate some suggestio…

Quoting what a HN user said in another post a few months back "if a person can break a system, the system was broken to start with".

Eh, that's a nice thing to say, but it only makes sense at certain scales, and no matter what, there's always a person that can break it.

If any random person can break it, it's already broken.

If any employee can break it, it's probably broken (there are very small scales where even this doesn't apply. Ever worked for a company with less than ten people? There's probably something any employee can break).

If any employee that's an engineer, sysadmin or developer can break it, well now you're at least reducing the problem to a more specific set of people.

If only the people on a specific team responsible for a system can affect the system, now you've reached fairly good point, where there's separation of concerns and you're mitigating the potential problems.

If only a single person can break the system, you've gone to far. That effectively means only a single person can fix or work on the system too, and congratulations, you've engineered yourself into a bus-factor of one. Turn right around and go back to making sure a team can work on this.

Finally, realize that sometimes the thing only one team can break is an underlying dependency for many other things, and they may inadvertently affect those. You can't really engineer yourself out of that problem without making every team and service a silo that going from top to bottom. Got a shared VM infrastuture, whether in house or in the cloud? The people that administer that can cause you problems. Don't ever believe they can't. Your office IT personnel? Yep, they can cause you problems too.

Some problems you fix by making it so they can't happen. Other problems you fix by making it hard to happen and putting provisions in place that mitigate the problems if they do.

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

#407

Post by jtolmar » Mon, May 31, 2021, 3:42 AM UTC

treis wrote: post #344

dehrmann wrote: post #182

Earlier quoted context omitted.

I end up reading the source half the time, anyway; documentation is often incomplete, dated, and possibly incorrect. For code, I'd prefer the time go into designing a cleaner interface and making what calls do obvious. That said, I find high-level documentation for larger systems to be very valuable. I also find Python's docs to be lacking compared to Java's; I'm often left wondering about the definition of what type…

>end up reading the source half the time, anyway; documentation is often incomplete, dated, and possibly incorrect. I'm a pretty firm believer that documentation has to live next to the code. Otherwise it's nearly guaranteed to be out of date and/or incomplete

100%

Thoroughly commented code tends to end up a couple changes out of date. A separate file in the same directory ends up a couple major refactors out of date. A separate file in a separate system ends up a couple company-wide reorgs out of date.

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

#408

Post by Rapzid » Mon, May 31, 2021, 3:43 AM UTC

EMM_386 wrote: post #148

aszen wrote: post #143

Earlier quoted context omitted.

It seems to like you are refactoring an existing application, I'm personally in the middle of something similar but rather than doing it solo, I'm trying to engage other Dev's, grab their interests by demoing the new architecture and see if I can get a few more hands on this work. I'm doing all of this extra work because I think the best way to create value for a company is to make it easy for other/new developers to…

> It seems to like you are refactoring an existing application, I'm personally in the middle of something similar but rather than doing it solo, I'm trying to engage other Dev's, grab their interests by demoing the new architecture and see if I can get a few more hands on this work. The problem is they literally can't afford it. They looked at "near shoring" companies but they were too expensive. They said we got a q…

I've never seen so many job opportunities in my life. Getting what you want out of employment right now should be as easy as filling up on vitamin D; just walk out the door.

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

#409

Post by jtolmar » Mon, May 31, 2021, 3:53 AM UTC

swader999 wrote: post #32

daenz wrote: post #18

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

What is wrong with making it up as you go? I mean everything I've ever built I had a notion of what I was doing but most of the real work was in the details. Anyone could say I was making it up as I go. I'd be like yeah, if I knew completely how to do it, I'd already be finished it. Then there's the times where you think you know exactly what you're doing and after going down a road you realize it's the wrong way. Fa…

> What is wrong with making it up as you go?

Nothing if you're good at it. But if you're hoping to learn something from someone, it is pretty disappointing. How to make it up as you go along is far less teachable.

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

#410

Post by bitwize » Mon, May 31, 2021, 3:54 AM UTC

Here's what I've learned as a senior SWE:

1) People skills dominate quality of work output in terms of value to the business starting at around this level. Really, introverts should avoid programming altogether which is weird because this was one of the few disciplines in which introverts could truly thrive but those days are gone.

2) What company leadership tells you they value has nothing to do with what they actually value. Look instead to what the company punishes you for doing or not doing.