141–150 of 241 posts
Earlier quoted context omitted.
I guess so. I haven't had a truly good one out of the 19 or so that I've had in 10 years.
If your manager is churning every six months, they are either bad managers or in a failing organization.
Where I am often hung up in comparison is due to age. I dropped out of college and spent my early 20s learning agriculture and construction. Now I work in software engineering and my current manager is younger than me. Not only is he younger than me, but he's been able to climb up to an engineering manager in a shorter amount of time than I've been working as a SWE. So I feel really lame - wasted so much time early i…
Which for me means that you don't yet know what advantage these 'wasted' years could give you in the future. Just trust yourself to make the best decisions you can given the circumstances and you'll get to where you want in as little time as you can.
Earlier quoted context omitted.
> "code quality" is not real, it's just something software engineers like to argue about like sports. While I do agree that many developers sometimes like to argue about "code quality" too much (and I've probably been guilty of that at times), "code quality" is definitely a real thing. I have have interacted with code bases that were a joy to read/modify, and I've interacted with code bases that made you pull your ha…
Probably I am being a bit hyperbolic. I could be more precise and say: code quality is a solution you should reach for if and only if you are running into real maintainability problems. But I strongly disagree with the sentiment that someone should not write code in a certain language, or should not contribute to a project until they know how to write idiomatically according to all the "accepted" best practices. It's…
Earlier quoted context omitted.
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.
None of that is "3days" . That's all the negative days before you start using the language. I could do all those setup things in N days without ever learning any programming language.
“3 days into the job”
Earlier quoted context omitted.
Except that's not at all what the article is suggesting. Quite the opposite.
> it is literally effortless to accidentally cultivate the impression of being some kind of wizard
Oh God. No. "Ensure that you are fulfilling the expectations of your manager" Please please do not assume your manager is any good at their job. Talk to your users. Find a way to identify them and get feedback from them. Keep your manager in the loop sure. But don't wait for requirements to come down from on high. "Every step up in job title is equivalent to living perhaps 1–2 days further into the future." No. If an…
I can guarantee you that no matter how good or bad their manager, if you don't meet their expectations, you are in trouble. By all means, own your local decisions, be proactive, keep your manager in the loop - AND MAKE SURE THEIR EXPECTATIONS AND YOUR WORK MATCH. That doesn't mean waiting for requirements, but that means your manager knows what you do and agrees, at least in broad strokes.
Surprising your manager unpleasantly never leads to good outcomes for you. There's only one person holding power in that relationship. (Positive surprises do work, but they usually take the form of "I did what you expected, AND".)
Totally agreed that the 1-2 days in the future thing is wrong. As a senior you should be at least a couple of weeks in the future, better if it's months. At the staff level, 6-12 months. At the principal level, 2-5 years.
If it's just a few days between each level, a) somebody is failing at their job, and b) yes, information will be outdated by the time it reaches you.
Earlier quoted context omitted.
> I'm sure he felt stupid when I pointed it out. He certainly did. There is no amount of experience that makes people not feel stupid about those. What changes is that you learn to not be affected by it, because you know that it's not a personal flaw (at least not one specific to you), and while you can improve on it, you can't completely fix it. But the alternating between feeling like the dumbest person on Earth an…
You develop tunnel vision and, whether someone points it out to you or you look at it with fresh eyes in the morning, it's a head slap "Duh."
After at least a few hours away (ideally not coding) your fresh eyes will often spot it.
Similarly, demoing the bug to someone else is a good way, and often through the mere act of demoing it you'll find it yourself (also known as "rubber ducking" [1]).
Earlier quoted context omitted.
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…
And Helm is just closing the cycle of Samsara - if you really want to base your operations on string templating, just use bash lol. Or hand-written forms on paper, still faster and you still get a better idea of what's going on.
There's also the problem of many developers nowadays just not having the hacker mindset/actual high-level abstract thinking/attention span, so instead of seeing the whole of K8S as the pointless kludge it is, they only see the interface - yay, YAML, I know that language! (usually they know it from everyone's favourite "dead" tool, docker-compose; which is a gem) - and they go on to fight with it tooth and nail, with corresponding feelings of "achievement" and "mastery".
I think the "10 years PHP/Java -> 3 days Go" thing from granduncle's cousin post is meant to point out this particular paradoxical situations.
But it could hurt people's feels to say it like that so let's just let Google do all our thinking for us instead. We truly live in a gilded age of computing.
Oh God. No. "Ensure that you are fulfilling the expectations of your manager" Please please do not assume your manager is any good at their job. Talk to your users. Find a way to identify them and get feedback from them. Keep your manager in the loop sure. But don't wait for requirements to come down from on high. "Every step up in job title is equivalent to living perhaps 1–2 days further into the future." No. If an…
Business leaders love to imitate the military, but isnt it ironic they are emulating the institution that has the most government involvement and central planning?