121–130 of 241 posts
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…
"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 organisation passes information down through the hierarchy then by the time it reaches you (it's more like 1-2 weeks if not months into the future) then it's already moved on.
The US military tries hard to put decision making at the front line where it is most up to date. At the Battle of Jutland the British ships in the fleet had to radio its positions and sightings back to London, so London could update its "board" and radio to the Admiral in the fleet. This Admiral was this working on data that ships a mile or two away from him had had hours ago, but he was only just getting. This lead to an inconclusive battle.
Anyway.
Open information is way important.
Earlier quoted context omitted.
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.
People in your company (including non-engineers) definitely care, because code quality bears on how easy it is to debug problems and how easy it is to implement new features or fixes (or sometimes if a feature is even practicable).
Earlier quoted context omitted.
"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.
Code quality is very real, but the bounds you have to exceed before lack of quality start to bog down development are pretty large. As a senior I can pretty quickly tell in the languages I write in often, when something is a smell, and if you keep repeating some code smells for a like a year you'll start seeing compounding effects on development speed. Understanding when to allow those with good reason and when to co…
The point where this happens depends a lot on problem domain. If you're doing well-understood CRUD-screen database stuff but applying it to a novel business domain, you're probably not going to hit code quality issues. If you're doing heavy algorithmic, OS, financial, or networking stuff, though, where failures compound and any one bug might take the whole system down, you really want to pay up for experienced developers that have seen all the ways these systems can fail.
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…
I take a different approach where I immediately point out the issue, and if they get discouraged about how fast I solved the problem, I remind them that I’ve spent hours banging my head against the same issue. They will probably run into this same issue again, and get stuck again, but next time they’ll figure it out faster, and the time after that a little faster, until it’s basically instantaneous. And then when they’re instantly able to solve a problem for a newb, they’ll have to give the same explanation as I’m giving now.
Earlier quoted context omitted.
A year? That's a very long time for anyone who isn't a novice to learn a new language.
I would bet hard money that even an experienced developer wouldn't learn C in a year (e.g. avoid or recognize most UB and security issues) without prior exposure. I'll grant that C is pathological in that respect though.
Learning a language and mastery are separate things. An actual experienced dev should be able to hit "competent" in any new language within weeks so long as it's within the same family of languages they've used in the past. Procedural languages, like C, are pretty much squarely in the middle of what everyone has learned unless by some fluke they started and continued with Haskell and similar languages and never touched any of: Go, Rust, C#, Java, Javascript, Lua, Python, Perl, Ada, Pascal, Fortran, Matlab, BASIC (various forms), and a hundred other languages.
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…
Granted this does not hold for 1) small startups where everyone has influence on the direction of the product and bureaucracy hasn't taken hold yet, and 2) FAANGS for the most part appear to operate under military like organization and allow for IC's to make decisions without 12 levels of approval.
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…
I basically learned ideomatic go in a week, by skimming over the "effective go" guide and cross referencing concepts to other languages I know -- there is really nothing inherently 'new' in Go that would require years. It's a deliberately simple language.
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…
If you want to be an IC, don't short change your accomplishments. Eng Mgr is not a promotion from IC, it's a career change.
The SWE career progression is much more established, and is often much more formal and understood than an Eng Mgmt track.
Your younger manager has recently gone through a significant career change that requires a significant amount of self-education to advance further. It's possible he'll advance opportunistically (if there's a vacancy) or by being clever or political, but his competency will not necessarily advance with him without him putting a significant amount of effort into learning this new career.
It's not uncommon for established SWEs to make more than engineering managers until the engineering manager has progressed to a level where they are dealing with levels of stress (business & social) that would make most people's hair fall out.
Even then many companies have career tracks that pay as well in the upper echelons for individual technical contributors as for high level eng mgrs. The one thing they have in common is that there are very few positions at the top of any career ladder. It gets competitive. Hopefully your aspirations match your talents so that you can compete for those fewer positions.