Live data from Hacker News

Senior engineers are living in the future

zerobanana.com

71–80 of 241 posts

Re: Senior engineers are living in the future

#71
post #23

Earlier quoted context omitted.

The trick is that Go isn't a new language, it's an old language with a new coat of paint.

3 days to learn how to write syntactically-valid Go or 3 days to learn how to write idiomatic Go? Idiomatic Go has some very large differences from idiomatic Java or PHP, including things like 1) the reliance on multiple return values and early exits for error handling 2) interfaces instead of inheritance 3) plain old data structures instead of everything-is-an-object 4) goroutines 5) table-driven testing 6) complete…

"code quality" is not real, it's just something software engineers like to argue about like sports.

We like to talk about how code is written, because we look at code all day. The rest of the world only cares about what your code does once it's compiled.

Senior engineers solve problems. They're not overly concerned with ticking all the boxes just so they can get a "good code" sticker.

Re: Senior engineers are living in the future

#72

Earlier quoted context omitted.

Well, golang is a tough language. I am stuggling with helm/kubernetes and the new company's ecosystem where everybody is new in the team. We are expected to deliver according to a plan while we keep hunting for relevant info. I would say the second point is a lot more nuanced than stated.

Saw a company fail because all developers were expected to master k8/helm etc. A couple of us got the hang of it well enough to get by. But almost everyone failed too. Even those of that had it working, it was a huge time sink.

That's why I'm a huge fan of server-less. Let Amazon or Google handle the tough parts until your company is big enough to have to optimize for server costs.

Re: Senior engineers are living in the future

#73
post #50

"The first—and most important—thing is to stop comparing yourself with others. Ensure that you are fulfilling the expectations of your manager and team for your development contributions." I have yet to see a manager or organization that doesn't compare on some level, even if it's just implicit biases.

No doubt. But It’ll be a more favorable comparison to you if you are focused on achieving your manager’s expectations, and proactively contributing to the larger org — not comparing yourself to others as your personal performance metric.

It’s obvious when someone is contributing to the organization in good faith / trying to do their job well, vs trying to edge out a colleague in specific eval criteria to look better. The second is not a good look, but I highly value (and reward) the first.

Re: Senior engineers are living in the future

#74

Earlier quoted context omitted.

> it is literally effortless to accidentally cultivate the impression of being some kind of wizard

My impression of that bit was that the author was saying it may look like a senior engineer is a wizard, but actually it's just experience and it's not magic.

> just

Re: Senior engineers are living in the future

#75

Not an engineer, but I find this translates well over to design. Seniority in a lot of ways feels like the acknowledgement of being able to utilize people/soft skills in order to build things. I find at least 1/3 to 1/2 of my time, a roadblock in the project is caused by accidental miscommunication from top down, and the faster you can debug those, the happier everyone will be. Personally I rather enjoy that hybrid o…

> utilize people/soft skills to build things

I love this! It can feel frustrating to need to use these skills to exert influence: I sometimes feel disempowered by not having the full resources to throw around that I want.

But that doesn’t really limit my ability to do the work. I’ve just had to cultivate a different skill set. Persuasion, not coercion

Re: Senior engineers are living in the future

#76

Earlier quoted context omitted.

A 10 years Java/PHP developer doesn't know how to use Golang on the job in 3 days.

Well, golang is a tough language. I am stuggling with helm/kubernetes and the new company's ecosystem where everybody is new in the team. We are expected to deliver according to a plan while we keep hunting for relevant info. I would say the second point is a lot more nuanced than stated.

> I am stuggling with helm/kubernetes and the new company's ecosystem where everybody is new in the team.

I can't speak for Helm, but working with Kubernetes in Go is almost uniquely difficult. Kubernetes modules are designed to be dynamic, and Go's type system doesn't make that easy, which leads to some cludge-y code out of necessity.

Plus the API is vast, and it's sometimes not clear what package you need for a particular use.

Re: Senior engineers are living in the future

#77

a great article, we software engineers are impatient and we tend to job hop often. Being an effective engineer is about more than knowing how to build systems and code, it also requires deep domain knowledge into your company's business and existing systems and this knowledge takes years to cultivate at the same company. All the superstars at my current company have been here for a while.

We job hop for a number of reasons. The primary one being compensation when their current job isn’t keeping up with inflation. Another is lack of promotion when you went above and beyond (as you were coached to by your manager, for that promotion). Another reason (which is why I do) is that life for some of us isn’t as stable. I move. I’m forced to sometimes because of rent. Sometimes that means having to find a new,…

While I agree with the reasons you outlined, my experience so far shows that number one reason is being the impostor. Most people I've had displeasure to work with job hopped because they got the job through lies, which showed when faced with bearing responsibility and having to finish the project, I've seen many just jump the boat.

Re: Senior engineers are living in the future

#78
post #20

One of my classmates in college couldn't handle this. I'd glance at some awful Visual Studio compiler error and then point out a missing semicolon. He ended up feeling stupid, but I was trying to be encouraging because his code was pretty good aside from some missing punctuation, which will come with practice. He ended up switching majors.

I find that egos can be really fragile when people are just starting to learn things. Pointing out the mistakes so quickly can seem like a great help (and it is!) but some people react like they're staring at the sun. Instead, I find it better (except for how long it takes) to walk them through finding the problem as if it's really hard and just nudging them to the steps they'd need to take to find it themselves. The…

Perhaps this is really stupid and juvenile, but the show Adventure Time had an episode where one of the characters said “sucking at something is the first step to being kind of god at something.” I think that’s an important lesson a lot of people should learn. Going out and sucking it up is awesome if it means you’re getting better at something.

Re: Senior engineers are living in the future

#79
post #50

"The first—and most important—thing is to stop comparing yourself with others. Ensure that you are fulfilling the expectations of your manager and team for your development contributions." I have yet to see a manager or organization that doesn't compare on some level, even if it's just implicit biases.

No doubt. But It’ll be a more favorable comparison to you if you are focused on achieving your manager’s expectations, and proactively contributing to the larger org — not comparing yourself to others as your personal performance metric. It’s obvious when someone is contributing to the organization in good faith / trying to do their job well, vs trying to edge out a colleague in specific eval criteria to look better.…

That hasn't been my experience. I've even had managers pit devs against each other.

Re: Senior engineers are living in the future

#80
post #23

Earlier quoted context omitted.

The trick is that Go isn't a new language, it's an old language with a new coat of paint.

3 days to learn how to write syntactically-valid Go or 3 days to learn how to write idiomatic Go? Idiomatic Go has some very large differences from idiomatic Java or PHP, including things like 1) the reliance on multiple return values and early exits for error handling 2) interfaces instead of inheritance 3) plain old data structures instead of everything-is-an-object 4) goroutines 5) table-driven testing 6) complete…

Really all it is is "3 days to showcase you have a working compiler, ide, formatter, can run the tests, and are familiar with the CR tools".

The rest of it is learned (hopefully quickly) through the CRs, and any senior engineer should be comfortable making a few idiomatic mistakes in their CRs that they learn from.

Post reply on HN