HN headline tomorrow: Senior engineers are literally gods
Senior engineers are worms. Bow before the principal engineer.
Senior engineers are living in the future
41–50 of 241 posts
Re: Senior engineers are living in the future
#42One 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…
Some people are lucky enough that the things they focused on early in life are things they were good at. Unfortunately, I think some subset of those people also develop an aversion to things that they don't appear to reach competence in as quickly as prior endeavors.
That's a shame, because often I think people that have competence in a subject come naturally to them end up at a disadvantage later, because their foundational knowledge is lacking (at least in cases where that's possible and learning was self driven).
One example of this is learning a programming language through doing compared to actual study and research. By "doing" I'm not referring to a project to cement details, but for example how most people know bash.
Another example would be spoken languages and some of my college professors. I'm not sure I ever heard anyone speak with as good of a vocabularity and diction as one of my CS professors that English wasn't his first language.
Re: Senior engineers are living in the future
#43Earlier quoted context omitted.
I would never fault someone for not being able to pick up a language and use it competently in 3 days. I understand why you use this as an example, with having samey syntax, but there is still nuance. I think the bigger indicator is you've been in the industry for 10 years and call yourself a PHP/Java dev. At this point you should have dabbled in probably 10-100 ways of solving problems depending on what your 9-5 loo…
Who said you need competence, looks like that was your own insertion, haha. But seriously is it not unreasonable to be able to write some non-deep dive code in a new but similar language in just a few days? 3 days is a long time to read and ask questions.
What purpose does it serve though? I think being able to read and understand a Go program is a better example. That does seem like a reasonable and useful ask in 3 days for a veteran PHP/Java dev, and something that is more likely to come up in practice. What is the context of the former? "Welcome to our team. I know we didn't hire you as a Go dev. You have 3 days to "be able to write Go".
I have long subscribed to "A programmer is not language specific", and I don't hire based on the languages you know. But that first task is "Here is access to the repo. Read and understand what our code does today please. I'll answer questions within reason." Acquiring the new language happens as a side effect.
Re: Senior engineers are living in the future
#44Earlier quoted context omitted.
Why is 3 days, likely with competing priorities, a reasonable timeframe to learn a new language well enough to contribute production code in your estimation?
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 reliance on gofmt for formatting rather than doing it manually. And that's just the stuff that I'm aware of, as someone whose primary language is not Go but worked in it for about 3 months.
My definition of a senior dev would be someone who's aware that they can't just pick up a language in 3 days and write idiomatic good-quality code, but expects that they're going to have to keep learning for multiple years to really master a language. It's the metacognition of realizing how little you know and always continuing to learn.
Re: Senior engineers are living in the future
#45Earlier quoted context omitted.
A 10 years Java/PHP developer doesn't know how to use Golang on the job in 3 days.
In other words you're inventing some silly criteria that I'd guess you'd pass that others wouldn't. What I would say to that is that if you dismiss someone else's experience because they can't do some task you think they should be able to do rather than understanding that their experience probably brings something else to the team then that's your failing, not theirs. For a little annecdata - I've been a dev for 25 y…
> a talent for technical writing, a belief that documentation is actually important
This is, IMO, a hallmark of "senior" engineers and above. Much more important than language adoption/choice.
Re: Senior engineers are living in the future
#46Earlier 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.
In what way were the developers expected to "master" k8/helm? In the sense of actually making contributions to the k8/helm setup, or simply using an existing k8/helm setup to provide a development environment? Was there any "expert" person on the team that everyone could ask about k8, or was everyone simply supposed to pick things up on their own?
(asking because my own team is currently moving in this direction, and I'm curious about the pedagogical challenges we might face)
Re: Senior engineers are living in the future
#47Earlier quoted context omitted.
Can you give an example of a failure at step 2?
A 10 years Java/PHP developer doesn't know how to use Golang on the job in 3 days.
"Use" is pretty vague. Can run the process and make a small fix should be easy. Writing idiomatic code in a new language takes months.
Re: Senior engineers are living in the future
#48Senior means two things: - Have experience - Self learning though above experience. I met many experienced developers, but most of them failed at step 2. To me, they're still junior.
My friends who won't step 2 mostly because they are limited by their circle's culture. There is this large enterprise corp network that can keep you stable forever, these guys never see outside world so global maxima is not a thing.
Re: Senior engineers are living in the future
#49Earlier quoted context omitted.
A 10 years Java/PHP developer doesn't know how to use Golang on the job in 3 days.
Had a guy with 20 years experience at a top mail carrier come in for a senior position. We were very excited to interview him. He had spent the 20 years copying the same html file and changing the text for whatever was needed. Struggled heavily with the concept of a loop.
"He had spent the 20 years copying the same html file and changing the text for whatever was needed."
Dream job right there.
Re: Senior engineers are living in the future
#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.