Something that I find interesting is that career advice coming from professionals having many years of experience focuses almost exclusively on the people aspects and not the technology: communication, trust, teamwork, documentation, clarity. The advice is clear, precise and honest.
This is the opposite of what you get from new hires/juniors: they tend to focus on which stacks matter, what to learn, how to develop, deploy and maintain. Not much real advice on the behavioral side, to the point that people often take trainings for behavioral interviews and memorize “leadership principles” and other nonsense.
What you're saying is important for everyone to internalize. I'll spin it like this:
Your job satisfaction/pay are a function of your impact. Your impact is a function of your leverage.
If you're a "pure coder" who doesn't have any of the other skills you mentioned, your output is incredibly limited. At best, you produce a day's worth of code in a day, but you also require someone to manage you closely to make sure you code the right stuff.
The more of these other skills you have, the more you can (a) work independently (b) make others more productive and (c) make sure your team/business is doing the right things and (d) drive overall efficiency.
The more of these things you do, you become orders of magnitude more impactful than a pure coder.
I entered the industry with no degree, having taught myself to code. After approx 15 years as a developer, I decided to get a degree, because it was becoming a problem (Australia is very sensitive to qualifications). I decided to get an MBA because all the hard problems I'd met were people and/or business problems.
The tech is generally easy in commercial coding. There is usually a definitive answer, and if not then the trade-offs are generally well-known. It's rare to run into a problem that requires complex technical knowledge, and in those cases it's fine to hire a consultant to help.
But the people problems are hard. Getting clued-up on these is important.
Generally speaking - your technical qualifications value over a replacement hit their peak sometime between 3 and 10 years into your career for most folks. Meaning while you may be particularly skilled, learning one more discipline, stack, technique, or language probably won't let you get a particular job done any better or faster than the next engineer.
Many engineers move to management at this point, which requires that you can mentor and grow a team of engineers, set goals, drive projects to completion, and manage your team through performance reviews.
Folks who stick to the technical path need to become an indispensable piece of technical glue across N teams, keeping them all building in the right direction and not crushing each other. This job requires deep technical knowledge but often doesn't involve a ton of coding e.g. Linus Torvalds.
If a junior engineer showed up with the behavioral qualifications of Torvalds and the technical skill of a junior engineer - they would still be a junior engineer and unable to build trust, guide a team effort, or other activities.
Hum... maybe it's because they have so much technical expertise that they are able to have insights into other things?
Technical knowledge is still very important, and it's the basic foundation of being a software engineer, and maaaaannyyyyyy people out there don't even know the basics.
This is the opposite of what you get from new hires/juniors: they tend to focus on which stacks matter, what to learn, how to develop, deploy and maintain. Not much real advice on the behavioral side, to the point that people often take trainings for behavioral interviews and memorize “leadership principles” and other nonsense.
This was exactly the experience I had not so long ago.
Management brought in a new "team leader" to "shake things up" with "new ideas."
She spent most of her time reading management books, taking online management courses, and going to management seminars. She almost never spoke to the "team," and when she did, treated us like underlings.
They gave her two years to make a difference, and then kicked her out in the first round of COVID cuts.
This is not just a junior problem. A lot of "people problems" seem to come from fighting over which stack to use. (and most people fight for whichever stack they are best at, to maximize their own personal contribution). I always spend a lot of time asking people what technology they would use to solve a particular problem, what technology they really don't like, etc. It saves a lot of trouble fighting over things if you get a team that is willing to go with a particular technical approach and is more important than most "cultural fit" issues.
>Not much real advice on the behavioral side, to the point that people often take trainings for behavioral interviews and memorize “leadership principles” and other nonsense.
This is what FAANG interview generally look for so why is it a surprise that potential hires focus on it? Amazon literally says that you need to highlight all the leadership principles in the stories you tell when answering behavioral questions. Granted, FAANG barely asks behavioral questions for senior engineers (and then it's like 90% project and bureaucracy management) much less junior engineers.
Most juniors have a much narrower focus in their day to day activities. Their responsibilities tend to be far more focused on churning code and dealing with cool or bad tech choices, whereas the more senior you get, the wider or high level your job can become.
professional interview sign seen at the "interview desk" for work placement at an expensive school for digital creatives: "sit up straight; look the interviewer in the eye; wear presentable clothing; answer the questions asked of you" .. I believe the sign was there because that was not occuring in many cases !
3. Simplicity
Fighting complexity is a never-ending cause. Solutions should
be as simple as possible. Assume the next person to
maintain your code won’t be as smart as you. When you can
use fewer technologies, do so.
This is the one I appreciate more and more as I age. Because frequently, I'm the next person looking at my own code. And there's no better gift to your future self than well-written, easy-to-understand code that is straightforward to maintain.
"When I was at GM, you were a failure if your next move was not up—managing more people or taking on bigger, more complex projects. For many, this made for a miserable career path"
As I've said before, I think this is a corrosive aspect of the perf/promo process at many FAANGs. The "level" system encourages/pushes people to "upgrade" in this manner, and I think contributes to a number of problems. For one, organizational incompetence when people who were valuable contributors where they were are elevated up into roles where they no longer can apply those skills as effectively (i.e. technical team lead to management or architect) leaving a vacuum below. A form of the Peter Principle I guess, except the individual may have competence in their new role but not be happy, or make the team itself less successful.
And most importantly, as he touches on: being asked to 'level up' and told that this is your mission can lead to an unpleasurable career. Either when you do get that promo and then find that you don't enjoy the new responsibilities (but become trapped by the position / upgraded compensation etc.) or when you don't get the promo (or don't try) and find that your value in the eyes of yourself and others seems less.
And finally, I think this type of thing can really take hold in places with a highly academic background / focus / origin (like Google, etc.) as it mimics in many ways the grade / peer review achievement structure of academia. And that reward / grading structure may not at all correspond to either the monetary or cultural success of a corporation.
Smaller companies looking to grow/formalize should exercise caution when looking at the rating/performance/promo process @ FAANGs / MS as a model for their own.
(I'm at 20-25ish years in the industry, but really feel junior in so many ways when I read the words of veterans like this.)
> “ When you know something it is almost impossible to imagine what it is like not to know that thing. This is the curse of knowledge, and it is the root of countless misunderstandings and inefficiencies.”
A few months ago I came across an interesting actively developed project in embedded rust which was very technical. Full of acronyms and concepts that I was not familiar with. It took quite some time to get up to speed with how it all worked and so I took the time to add / expand README.md files for each example, explaining what the acronyms meant and the general gist of each example. It was a worthwhile exercise for myself and I figured that it was worth sharing the perspective of a beginner too. My benign pull request remains ignored and unmerged and it makes me feel like a bit of an imposter. I thought nothing of it at the time but now I wonder if this is classic case of “the curse of knowledge”. Perhaps the author just can’t see the value of it.
What I'd be really interested in is how tech churn is perceived by people older than me. I'm only 30 years in, so I tend to defend my generation's choices such as POSIX, SQL, XML, SOA, Java, and C/C++ before that (plus special-purpose pet peeves of mine such as markup/SGML and logic programming which came before) though I'm also claiming to be proficient in and generally open towards new tech. I consider most of supposedly new tech as rehashes of things past rather than real progress, and to be just lock-in schemes and sucking in another way compared to the tech that it is supposed to replace. But I'm really uncertain if I'm just falling victim to generational effects, like, say, the proverbial COBOL programmer being ridiculed by younger devs to instinctively grow their own tech career. Still, for me, there's a moment around 2006-2012 when the industry went all-in on "the Cloud" and consumerisation of IT, when before I saw canon, progress, and consensus through standardization.
I guess this is something that can't be objectively measured; but I can say that initiatives for standardization have almost dropped to zero compared to the 1990s and 2000s.
> initiatives for standardization have almost dropped to zero compared to the 1990s and 2000s
I think OSS adoption explains this. Standards were all about advocating for common interfaces, even if the implementations were proprietary. Proprietary software was more a thing in the 90s and 00s.
Nowadays, common practice is to use open implementations, not just open interfaces. Nowadays, we only see widespread initiatives for standardization when people are trying to cement the long-term survival of their implementation's interface.
See, for example, the Open Container Initiative, put forward by Docker (a company that engineers were concerned about betting the barn on, in 2015).
Contrast that with S3, which does not have a corresponding commitment to an open interface standard. Their interface has been copied nonetheless by several vendors (DO, Linode), making it a de facto standard, albeit a fragile and autocratic one.
Basically, I'm not sure if standardization has evaporated, I think it's diffused, and OSS is (ironically?) a contributing factor.
I'm only 15 years in but have thought about this a lot. I agree with you that there is nothing new under the sun; that we just cycle back through old ideas; fashions come and go and come back.
However, the environment changes so often old ideas go from being "possible" to "they just work" or "possible but really slow" to "instant".
These environmental changes can make orders of magnitude differences, and cause old ideas to suddenly feel very different in practice.
When I think of programming languages for example, of the languages you mention, a lot of their design (like matched brackets in XML), were decisions that made a lot of sense when we had monochrome editors, but now with extremely fast and advanced IDEs, we can take old PL ideas from the 50's and design languages with IDEs in mind that are a lot less cryptic and concise.
Very interesting indeed and I had some glimpse of that in my dad, who all his life worked for only one company. And especially as I got older and interested in computers he started talking about some work stuff sometimes. His first programming language at work was 360 assembler. For the uninitiated/too young to remember: https://en.wikipedia.org/wiki/IBM_System/360. When I started working at the same company for my first job and I had to log into 'the host' - meaning the IBM mainframe they had (I believe by that time a Z series https://en.wikipedia.org/wiki/IBM_Z) I noticed how the custom login screen for their entire system had actually been written by my dad.
So all this just as a little context. But when I was talking about SQL like 15+ years ago he would always tell me that sure that's nice and all, but all those joins. They're painfully slow. Why would you do that? They had a table that had exactly all the information that they needed to have and they accessed it via a key. Fast and easy. Need a different view of the data? Make a new table that's organized the way you need it. Done and fast. Ring a bell? (NoSQL :))
I also started playing with Linux and system administration and obviously virtualization (vmware at the time, qemu stuff etc.). So I go talk to my dad about it and how I love the concept and how it does X and Y and Z cool thing. Yeah well, for him that was really old stuff, coz they had that on their mainframe since like forever (now called z/VM, then called VM/370 - in 1972).
We had to learn and use Java at university, which my dad always made fun of. Especially with articles like "The state of Java application middleware" and such that I was looking at. All that new fangled stuff, pah! He had been working with IBM CICS as the middleware for forever. Initial release of CICS July 8 1969, latest release June 12, 2020. (https://en.wikipedia.org/wiki/CICS)
I get it. I say the same thing(s) about some of the new fangled stuff I have to work with nowadays. With the kids. Some of it is great. Other things I'm just asked myself why the wheel had to be re-invented just to come back to square one. Like NoSQL databases that add features you'd expect from relational databases.
As a young blood, 5 years in, got hired by learning react in the great JS hiring of the mid 2010s, I look back towards those standards bodies as something that would be very beneficial now. All we have is chrome creating standards by monopoly.
Maybe I have a older mindset aswell. My training in in Civil Engineering and I have my expectations for standards bodies set pretty high because of it.
The code is so high level now, going through algo and data structures I see the benefit of that fundamental knowledge, but also see that you can be a very valuable engineer to a company without it(thanks to the rich developer ecosystem for that)
If we think about the maturity of software like a biological ecosystem, maybe the zen garden built by past engineers has overgrown into a dense and varietal forrest. Im not sure if its bad or good, maybe there are more niches to move into.
I think one source of tech churn people don't talk about is just growth. If you're 5x size you were last year, an entire system rewrite is relatively cheap, and if you expect to grow in the future, you can make riskier bets knowing they'll be cheaper to replace down the line. It's not ipso facto irrational. I'd be interested in seeing a breakdown of the correlations.
I'm 30 years into this industry also. We all have a tendency to defend and use what we're comfortable with, which often is what we learned ages ago. I try to challenge myself regularly by looking for my biases and assumptions. (Easier said than done, of course.)
However, I'd say the rate of "tech churn" has become impossible to keep up with in the most popular stacks (Java[Spring], .NET, front-end, Node). If you are in other areas, things tend to move slower.
I think the initiatives for standardization move at about the same rate as they used to, but the increasing amount of industry churn makes it seem like standardization has slowed down.
> Clean, understandable, and navigable code and design
It's interesting to see "navigable" in here - I've struggled to articulate in the past this problem and I think this nails it. We often see simplicity come at the cost of "navigability". All the configuration by convention frameworks have this problem particularly heavily. I'm often at a complete loss to trace the mechanics of what is happening in things like vue-cli, Rails / Grails, gradle, and many other dynamic frameworks.
They achieve remarkable simplicity, yet I often end up hating them and swearing at them because I can't exercise my understanding of fundamentals to reason about them and rationalise what they are doing. "The database connection must be getting established somewhere - it should be traceable back from the point where the connection is used in some way" - well, no you may have to understand most of the entire underpinnings of the framework before you will achieve that understanding.
I think this "navigability" idea really fills that gap well. Things should be simple, but they should always stay navigable based on fundamental knowledge.
Webpack is one of my absolute favorite tools. It's easy to reason about and a pleasure to use. It absolutely checks the "navigable" box in my book.
However, it got constant flack (esp. here on HN) for being too complicated. Apparently asking a dev to spend a day learning the tool before getting started on a new project was too much to ask. Now the best practice is to use a meta-tool like vue-cli or react-scripts to abstract away Webpack, trading navigability for simplicity. Simplifying complex tasks requires magic and good luck debugging when your magic incantations don't work as expected.
I totally agree that navigability is super important and I wish I knew how to better emphasize it in my projects over the "batteries included" approach that has the best marketing.
I agree, and I like the concept of "navigability". But I'm not sure I agree that many of the listed frameworks like Rails, are simple in my experience. There is a lot of "magic" complexity, but they just go through efforts to hide that complexity from you. It appears simple on the surface, but on deeper dive the complexity is still there.
what does navigable mean? I expect the IDE/tools to allow you to navigate the code fast and easily. If your IDE doesn't let you click-thru to definition, usages, and references, it's a poor setup imho.
One of the tenets though, "6. Be Honest and Acknowledge When You Don’t Fit the Role" only is fair to the person if the team/company also follows that advice.
If a team or company does not value, or cannot tell, or does not act if someone is incompetent and unfit for a role, then this advice penalizes those who are honest, and rewards those who are good at faking competence.
You need to have a structure of integrity within which to operate, in order for honest behavior to be rewarded.
> Computer Assisted Software Engineering (CASE) tools, COTS, Enterprise Resource Planning products like Peoplesoft and SAP and, yes, even Ruby. They claim amazing reductions in cost and time if you buy into their holistic development philosophy. What is not always as obvious is the significant up-front costs or the constraints you may be committing yourself to. Lock-in used to primarily happen with vendors, but now it can happen with frameworks too.
It is no? It's not easy to rewrite into something else if you need to. With rails the biggest reason you might need to do that is the abysmal performance. You need twenty servers to do the work you could have done with one.
Is it not? Even if it's open source, I would view monolith frameworks as a form of ecosystem lock-in. We use Spring at work and I would certainly describe us as suffering from "lock-in" to the Spring ecosystem.
It's hard not to become jaded when every framework turns out to be just another team's personal preferences. I would say the statement is generally true about frameworks, but not true about rails. Perhaps the author did not spend enough time with rails.
I read '5. Beware of Lock-In' section as "be generalist".
It looks to me as generic career advice to not stay fixated to single all-in-one tech choice and role - SAP dev, Ruby dev etc. Ruby is just an example here ('even', 'frameworks too'), I guess the author witnessed the "rockstars" and evangelists hype wave of RoR circa 2005-2010. Possibly it could be e.g. ReactJS or Kubernetes today too.
yes, but lock-in can be worth it, and Rails is increasingly worth it as the ecosystem and core grows. i wish we had an alternative term to "lock-in" that had more neutral instead of negative connotation. it's got tradeoffs, like with anything, but doesnt mean we gotta be scared of it.
But all too often, the very best possible advice is, "Get out. Get out now!"
Get to a place where the Good Advice quoted above works. It can be very hard to tell that, up front. You have to try and see, and plan to skip along if you guessed wrong.
Most of my regrets, over 45 years in engineering, are over sticking around when what I had to offer was not what was welcome. Sometimes, what they needed, I didn't have. Other times, they didn't know what they needed, didn't want to know, and didn't recognize it under their noses. Either way, you would much better be elsewhere sooner than later.
For the young, it is tempting to try to prove your bosses wrong. That never, ever works. First, sometimes they aren't. When they are, they will be committed to not seeing it. It is always overwhelmingly better to deliver solutions to people eager to get them. So, find those people.
Often, you will have to prove yourself and the value of your ideas. That is not a reason to scram. But make sure before you start that success has a definition. "Ten times faster", "ten times cheaper", "ten times fewer server instances", "ten times less latency", "ten times less downtime" are hard to mistake, are remarkably often achievable, and are sometimes welcome.
In some cases, "two times" stands out; I recently got Quicksort to go twice as fast, and that drew some notice.
1. Politics is everything - how you are perceived is politics, whether you get assigned the projects you want is politics, career progression whether technical or managerial is entirely politics. You will be told various nonsenses about 'flat structures' and 'meritocracy' throughout your career but it's bollocks. Play the game badly and the flat structure is your career.
2. Most programmers don't care - as much as you might care about software engineering principles or even minimal levels of quality in your work, you will be shocked at the degree to which most of your colleagues do not. They might give lip service to it but when it comes to it most justify doing a crappy job by hand waving about being practical. If you talk even mildly about code quality expect to have it patronisingly explained to you 100 times over that you are a perfectionist and customers don't care and etc. Etc. (Of course these arguments are easily rebutted straw men but good luck getting that across).
3. Raising what's right usually hurts you - people do not like to hear uncomfortable or irritating truths. See point 1. Pointing out that something is a risk or severely broken is more likely to get you hassle and lower people's view of you and God help you if you are proven right - there is never a 'oh you were right!'. Nobody likes to be made to look bad. Again see 1.
4. Never underestimate how shit the code is in your next job - the interview very rarely gives you the slightest insight into the quality of a new employer's codebase and never be surprised at just how terrible it can be.
5. We'll fix it later means we will never fix it - technical debt is a lot like national debt - ever growing and rarely paid down. If you are fobbed off with a 'we will refactor that later' comment take that to mean 'this is shit and I am fine with that'.
6. Sideways shifts reset your career to zero - there is no such thing as treating development experience as fungable. You are only as good as your years in this particular slice of the industry and more often than not you are only as good as your years in this particular company.
7. Fuck you pay me - at any time if you are told by an employer that you are part of a family or that your pay rise couldn't happen because you are already paid highly for your title or other such nonsense, start looking for another job, you are being used.
> 6. Sideways shifts reset your career to zero - there is no such thing as treating development experience as fungable. You are only as good as your years in this particular slice of the industry and more often than not you are only as good as your years in this particular company.
This one has burned me a bunch of times in my career already and I'm not quite a decade in. I really want to find a corner of the industry I can focus on and gain momentum in my career but it's been challenging to do that.
This is really good advice. Myself personally, I have been programming for decades as well and struggle with the curse of knowledge.
Curious what other people do and what struggles they have had.
Having spent time studying Category Theory I see a lot of value to using it in my code but it is not common knowledge and often confuses others when you start throwing around terms like functor, monoid, monad, etc.
At the same time I don't want to write code that isn't as reusable or to that isn't as maintainable.
Are we as an industry limiting our own potential by deliberately not using knowledge when it is beneficial for the sake of greater communication?
My personal philosophy when working with teams is to exclude some of that stuff but slowly introduce it and train junior developers on some of the concepts in the hope that I can push that knowledge forward.
Curious what others think of this dilemma and how they address it.
I also struggle with this issue, but I've never heard the term "the curse of knowledge." I'm happy I have a name for it now. When you try to explain to people that it's difficult to understand that other people don't know something that you know, you sound a little crazy.
I'm only 7 years into my professional software engineering career and this really stuck with me. Over the last two years I had the honor to work with an awesome team on an interesting project, and yes, trust is the basis of exceptional teamwork.
I'd like to add, that knowledge can lead to "knowledge paralysis": The more knowledge and experience you have on a certain topic, the more problems and caveats you'll spot right away. Awarenes of those may prevent you from actually engaging in productive activity and instead tiptoeing around the problem at hand, instead of just implementing a "straightforward" solution (that ignores the 0.1% of corner cases, you know about, but won't have to care about).
This is omething I'm struggling more and more these days.
> At EDS, the culture wasn’t like this. People moved in and out of management roles. There was no stigma associated with moving from roles with greater scope, like strategic planner, to roles with more narrow scope, like PM or project-level developer.
This sounds amazing. I'm curious...how does salary change? Or does it change? How is all of this handled...
Stuff I'd add that I think is crucial, and all related to one topic: good writing!
1. Learn to write specs
Call it an RFC, call it a PRD, call it whatever. Writing out a plan for any project taking around a week or more is always worth it. Use it to establish scope and priorities. Keep a "Questions" section that you whittle away at as you seek out feedback. Make the body a hierarchy of design tasks and implementation ideas. Track revision history and keep it up-to-date.
You now have a great way to get sign-off from peers + management, an execution plan, a task breakdown for ticket management and historical documentation on what happened and why.
2. Be terse
Is that email looking a little long? Write a "TL;DR:" section at the top and then see what you can delete. If it's nothing, leave the "TL;DR:". Otherwise you may find you've included a lot of intermediate thinking and people only need to know the conclusions.
3. When learning something new, keep a dedicated list of "this looks like magic!" items
Use your "down time" to research items on this list instead of refreshing your favorite news aggregator. Ask your peers and mentors about them. Notice when tangental issues come up and spend a few extra minutes seeing how they're related and how that might yield some easier answers.
4. When you want to ask for help... defer clicking "send"
Whether its an IM or email, write it up on the side first. Start with your question and follow-up with what you've already done to walk through finding the answer to save the person the effort of starting from step one or pointing out the obvious thing you overlooked. Often this will lead you to answering your own question. If not, still wait 15-30 minutes (if you can) before sending it and work on something else. In that time you're likely to think of something you overlooked and avoid interrupting anyone.
Even if I am moving my first steps into the industry (I'm a simple trainee at a Tech-StartUp and MSc student) I've already experienced many times the first point. I think trying to keep your feet (and mind) on the ground, even when you have a huge expertise is fundamental in communication, teamwork and goals' chasing.
For example a friend of mine, graduated in one of the top programs in europe at Rotterdham Business School, has a huge expertise in the R language, he is able to manage data promptly at work, efficiently delivering in 2 hours what his colleagues do on Excel in the whole day. However he has big problems in communication here in Italy, he is not able to understand what other people with different background/expertise are asking to him precisely and this is becoming a huge issue in terms of career development.
>> When you know something it is almost impossible to imagine what it is like not to know that thing. This is the curse of knowledge, and it is the root of countless misunderstandings and inefficiencies. Smart people who are comfortable with complexity can be especially prone to it!
The more I learn about smart people, the more I realise how dumb they are.
Regarding simplicity, I’ve observed the following about design. Usually, designs become more complex with time. If the RATE of complexity increase exceeds a certain level, the design is crap and that approach needs to be scrapped. Occasionally, a design gets simpler as one goes forward. THOSE are magic!
[+] [-] lrossi|5 years ago|reply
This is the opposite of what you get from new hires/juniors: they tend to focus on which stacks matter, what to learn, how to develop, deploy and maintain. Not much real advice on the behavioral side, to the point that people often take trainings for behavioral interviews and memorize “leadership principles” and other nonsense.
[+] [-] xyzelement|5 years ago|reply
Your job satisfaction/pay are a function of your impact. Your impact is a function of your leverage.
If you're a "pure coder" who doesn't have any of the other skills you mentioned, your output is incredibly limited. At best, you produce a day's worth of code in a day, but you also require someone to manage you closely to make sure you code the right stuff.
The more of these other skills you have, the more you can (a) work independently (b) make others more productive and (c) make sure your team/business is doing the right things and (d) drive overall efficiency.
The more of these things you do, you become orders of magnitude more impactful than a pure coder.
[+] [-] marcus_holmes|5 years ago|reply
The tech is generally easy in commercial coding. There is usually a definitive answer, and if not then the trade-offs are generally well-known. It's rare to run into a problem that requires complex technical knowledge, and in those cases it's fine to hire a consultant to help.
But the people problems are hard. Getting clued-up on these is important.
[+] [-] lumost|5 years ago|reply
Many engineers move to management at this point, which requires that you can mentor and grow a team of engineers, set goals, drive projects to completion, and manage your team through performance reviews.
Folks who stick to the technical path need to become an indispensable piece of technical glue across N teams, keeping them all building in the right direction and not crushing each other. This job requires deep technical knowledge but often doesn't involve a ton of coding e.g. Linus Torvalds.
If a junior engineer showed up with the behavioral qualifications of Torvalds and the technical skill of a junior engineer - they would still be a junior engineer and unable to build trust, guide a team effort, or other activities.
[+] [-] burade|5 years ago|reply
Technical knowledge is still very important, and it's the basic foundation of being a software engineer, and maaaaannyyyyyy people out there don't even know the basics.
[+] [-] reaperducer|5 years ago|reply
This was exactly the experience I had not so long ago.
Management brought in a new "team leader" to "shake things up" with "new ideas."
She spent most of her time reading management books, taking online management courses, and going to management seminars. She almost never spoke to the "team," and when she did, treated us like underlings.
They gave her two years to make a difference, and then kicked her out in the first round of COVID cuts.
[+] [-] philk10|5 years ago|reply
[+] [-] mattmcknight|5 years ago|reply
This is not just a junior problem. A lot of "people problems" seem to come from fighting over which stack to use. (and most people fight for whichever stack they are best at, to maximize their own personal contribution). I always spend a lot of time asking people what technology they would use to solve a particular problem, what technology they really don't like, etc. It saves a lot of trouble fighting over things if you get a team that is willing to go with a particular technical approach and is more important than most "cultural fit" issues.
[+] [-] marcinzm|5 years ago|reply
This is what FAANG interview generally look for so why is it a surprise that potential hires focus on it? Amazon literally says that you need to highlight all the leadership principles in the stories you tell when answering behavioral questions. Granted, FAANG barely asks behavioral questions for senior engineers (and then it's like 90% project and bureaucracy management) much less junior engineers.
[+] [-] zx14|5 years ago|reply
[+] [-] mistrial9|5 years ago|reply
[+] [-] trentnix|5 years ago|reply
[+] [-] cmrdporcupine|5 years ago|reply
"When I was at GM, you were a failure if your next move was not up—managing more people or taking on bigger, more complex projects. For many, this made for a miserable career path"
As I've said before, I think this is a corrosive aspect of the perf/promo process at many FAANGs. The "level" system encourages/pushes people to "upgrade" in this manner, and I think contributes to a number of problems. For one, organizational incompetence when people who were valuable contributors where they were are elevated up into roles where they no longer can apply those skills as effectively (i.e. technical team lead to management or architect) leaving a vacuum below. A form of the Peter Principle I guess, except the individual may have competence in their new role but not be happy, or make the team itself less successful.
And most importantly, as he touches on: being asked to 'level up' and told that this is your mission can lead to an unpleasurable career. Either when you do get that promo and then find that you don't enjoy the new responsibilities (but become trapped by the position / upgraded compensation etc.) or when you don't get the promo (or don't try) and find that your value in the eyes of yourself and others seems less.
And finally, I think this type of thing can really take hold in places with a highly academic background / focus / origin (like Google, etc.) as it mimics in many ways the grade / peer review achievement structure of academia. And that reward / grading structure may not at all correspond to either the monetary or cultural success of a corporation.
Smaller companies looking to grow/formalize should exercise caution when looking at the rating/performance/promo process @ FAANGs / MS as a model for their own.
(I'm at 20-25ish years in the industry, but really feel junior in so many ways when I read the words of veterans like this.)
[+] [-] davidhyde|5 years ago|reply
A few months ago I came across an interesting actively developed project in embedded rust which was very technical. Full of acronyms and concepts that I was not familiar with. It took quite some time to get up to speed with how it all worked and so I took the time to add / expand README.md files for each example, explaining what the acronyms meant and the general gist of each example. It was a worthwhile exercise for myself and I figured that it was worth sharing the perspective of a beginner too. My benign pull request remains ignored and unmerged and it makes me feel like a bit of an imposter. I thought nothing of it at the time but now I wonder if this is classic case of “the curse of knowledge”. Perhaps the author just can’t see the value of it.
[+] [-] tannhaeuser|5 years ago|reply
I guess this is something that can't be objectively measured; but I can say that initiatives for standardization have almost dropped to zero compared to the 1990s and 2000s.
[+] [-] gen220|5 years ago|reply
I think OSS adoption explains this. Standards were all about advocating for common interfaces, even if the implementations were proprietary. Proprietary software was more a thing in the 90s and 00s.
Nowadays, common practice is to use open implementations, not just open interfaces. Nowadays, we only see widespread initiatives for standardization when people are trying to cement the long-term survival of their implementation's interface.
See, for example, the Open Container Initiative, put forward by Docker (a company that engineers were concerned about betting the barn on, in 2015).
Contrast that with S3, which does not have a corresponding commitment to an open interface standard. Their interface has been copied nonetheless by several vendors (DO, Linode), making it a de facto standard, albeit a fragile and autocratic one.
Basically, I'm not sure if standardization has evaporated, I think it's diffused, and OSS is (ironically?) a contributing factor.
[+] [-] breck|5 years ago|reply
However, the environment changes so often old ideas go from being "possible" to "they just work" or "possible but really slow" to "instant".
These environmental changes can make orders of magnitude differences, and cause old ideas to suddenly feel very different in practice.
When I think of programming languages for example, of the languages you mention, a lot of their design (like matched brackets in XML), were decisions that made a lot of sense when we had monochrome editors, but now with extremely fast and advanced IDEs, we can take old PL ideas from the 50's and design languages with IDEs in mind that are a lot less cryptic and concise.
[+] [-] tharkun__|5 years ago|reply
So all this just as a little context. But when I was talking about SQL like 15+ years ago he would always tell me that sure that's nice and all, but all those joins. They're painfully slow. Why would you do that? They had a table that had exactly all the information that they needed to have and they accessed it via a key. Fast and easy. Need a different view of the data? Make a new table that's organized the way you need it. Done and fast. Ring a bell? (NoSQL :))
I also started playing with Linux and system administration and obviously virtualization (vmware at the time, qemu stuff etc.). So I go talk to my dad about it and how I love the concept and how it does X and Y and Z cool thing. Yeah well, for him that was really old stuff, coz they had that on their mainframe since like forever (now called z/VM, then called VM/370 - in 1972).
We had to learn and use Java at university, which my dad always made fun of. Especially with articles like "The state of Java application middleware" and such that I was looking at. All that new fangled stuff, pah! He had been working with IBM CICS as the middleware for forever. Initial release of CICS July 8 1969, latest release June 12, 2020. (https://en.wikipedia.org/wiki/CICS)
I get it. I say the same thing(s) about some of the new fangled stuff I have to work with nowadays. With the kids. Some of it is great. Other things I'm just asked myself why the wheel had to be re-invented just to come back to square one. Like NoSQL databases that add features you'd expect from relational databases.
[+] [-] scsilver|5 years ago|reply
Maybe I have a older mindset aswell. My training in in Civil Engineering and I have my expectations for standards bodies set pretty high because of it.
The code is so high level now, going through algo and data structures I see the benefit of that fundamental knowledge, but also see that you can be a very valuable engineer to a company without it(thanks to the rich developer ecosystem for that)
If we think about the maturity of software like a biological ecosystem, maybe the zen garden built by past engineers has overgrown into a dense and varietal forrest. Im not sure if its bad or good, maybe there are more niches to move into.
[+] [-] bananaface|5 years ago|reply
[+] [-] twh270|5 years ago|reply
However, I'd say the rate of "tech churn" has become impossible to keep up with in the most popular stacks (Java[Spring], .NET, front-end, Node). If you are in other areas, things tend to move slower.
I think the initiatives for standardization move at about the same rate as they used to, but the increasing amount of industry churn makes it seem like standardization has slowed down.
[+] [-] waldrews|5 years ago|reply
[+] [-] zmmmmm|5 years ago|reply
It's interesting to see "navigable" in here - I've struggled to articulate in the past this problem and I think this nails it. We often see simplicity come at the cost of "navigability". All the configuration by convention frameworks have this problem particularly heavily. I'm often at a complete loss to trace the mechanics of what is happening in things like vue-cli, Rails / Grails, gradle, and many other dynamic frameworks.
They achieve remarkable simplicity, yet I often end up hating them and swearing at them because I can't exercise my understanding of fundamentals to reason about them and rationalise what they are doing. "The database connection must be getting established somewhere - it should be traceable back from the point where the connection is used in some way" - well, no you may have to understand most of the entire underpinnings of the framework before you will achieve that understanding.
I think this "navigability" idea really fills that gap well. Things should be simple, but they should always stay navigable based on fundamental knowledge.
[+] [-] ng12|5 years ago|reply
However, it got constant flack (esp. here on HN) for being too complicated. Apparently asking a dev to spend a day learning the tool before getting started on a new project was too much to ask. Now the best practice is to use a meta-tool like vue-cli or react-scripts to abstract away Webpack, trading navigability for simplicity. Simplifying complex tasks requires magic and good luck debugging when your magic incantations don't work as expected.
I totally agree that navigability is super important and I wish I knew how to better emphasize it in my projects over the "batteries included" approach that has the best marketing.
[+] [-] Arelius|5 years ago|reply
[+] [-] chii|5 years ago|reply
[+] [-] supernova87a|5 years ago|reply
If a team or company does not value, or cannot tell, or does not act if someone is incompetent and unfit for a role, then this advice penalizes those who are honest, and rewards those who are good at faking competence.
You need to have a structure of integrity within which to operate, in order for honest behavior to be rewarded.
[+] [-] ChrisMarshallNY|5 years ago|reply
That suit...that hair...
He doesn’t really deliver any “wise mountaintop guru” stuff, though.
Just shows that good old-fashioned common sense is timeless (and distressingly rare).
[+] [-] SPBS|5 years ago|reply
Is the author calling Rails as 'lock-in'?
[+] [-] eloff|5 years ago|reply
[+] [-] __jem|5 years ago|reply
[+] [-] nahname|5 years ago|reply
[+] [-] imhoguy|5 years ago|reply
I read '5. Beware of Lock-In' section as "be generalist".
It looks to me as generic career advice to not stay fixated to single all-in-one tech choice and role - SAP dev, Ruby dev etc. Ruby is just an example here ('even', 'frameworks too'), I guess the author witnessed the "rockstars" and evangelists hype wave of RoR circa 2005-2010. Possibly it could be e.g. ReactJS or Kubernetes today too.
[+] [-] swyx|5 years ago|reply
[+] [-] steve_adams_86|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] ncmncm|5 years ago|reply
But all too often, the very best possible advice is, "Get out. Get out now!"
Get to a place where the Good Advice quoted above works. It can be very hard to tell that, up front. You have to try and see, and plan to skip along if you guessed wrong.
Most of my regrets, over 45 years in engineering, are over sticking around when what I had to offer was not what was welcome. Sometimes, what they needed, I didn't have. Other times, they didn't know what they needed, didn't want to know, and didn't recognize it under their noses. Either way, you would much better be elsewhere sooner than later.
For the young, it is tempting to try to prove your bosses wrong. That never, ever works. First, sometimes they aren't. When they are, they will be committed to not seeing it. It is always overwhelmingly better to deliver solutions to people eager to get them. So, find those people.
Often, you will have to prove yourself and the value of your ideas. That is not a reason to scram. But make sure before you start that success has a definition. "Ten times faster", "ten times cheaper", "ten times fewer server instances", "ten times less latency", "ten times less downtime" are hard to mistake, are remarkably often achievable, and are sometimes welcome.
In some cases, "two times" stands out; I recently got Quicksort to go twice as fast, and that drew some notice.
[+] [-] barnacled|5 years ago|reply
1. Politics is everything - how you are perceived is politics, whether you get assigned the projects you want is politics, career progression whether technical or managerial is entirely politics. You will be told various nonsenses about 'flat structures' and 'meritocracy' throughout your career but it's bollocks. Play the game badly and the flat structure is your career.
2. Most programmers don't care - as much as you might care about software engineering principles or even minimal levels of quality in your work, you will be shocked at the degree to which most of your colleagues do not. They might give lip service to it but when it comes to it most justify doing a crappy job by hand waving about being practical. If you talk even mildly about code quality expect to have it patronisingly explained to you 100 times over that you are a perfectionist and customers don't care and etc. Etc. (Of course these arguments are easily rebutted straw men but good luck getting that across).
3. Raising what's right usually hurts you - people do not like to hear uncomfortable or irritating truths. See point 1. Pointing out that something is a risk or severely broken is more likely to get you hassle and lower people's view of you and God help you if you are proven right - there is never a 'oh you were right!'. Nobody likes to be made to look bad. Again see 1.
4. Never underestimate how shit the code is in your next job - the interview very rarely gives you the slightest insight into the quality of a new employer's codebase and never be surprised at just how terrible it can be.
5. We'll fix it later means we will never fix it - technical debt is a lot like national debt - ever growing and rarely paid down. If you are fobbed off with a 'we will refactor that later' comment take that to mean 'this is shit and I am fine with that'.
6. Sideways shifts reset your career to zero - there is no such thing as treating development experience as fungable. You are only as good as your years in this particular slice of the industry and more often than not you are only as good as your years in this particular company.
7. Fuck you pay me - at any time if you are told by an employer that you are part of a family or that your pay rise couldn't happen because you are already paid highly for your title or other such nonsense, start looking for another job, you are being used.
[+] [-] bluefirebrand|5 years ago|reply
This one has burned me a bunch of times in my career already and I'm not quite a decade in. I really want to find a corner of the industry I can focus on and gain momentum in my career but it's been challenging to do that.
[+] [-] bcheung|5 years ago|reply
Curious what other people do and what struggles they have had.
Having spent time studying Category Theory I see a lot of value to using it in my code but it is not common knowledge and often confuses others when you start throwing around terms like functor, monoid, monad, etc.
At the same time I don't want to write code that isn't as reusable or to that isn't as maintainable.
Are we as an industry limiting our own potential by deliberately not using knowledge when it is beneficial for the sake of greater communication?
My personal philosophy when working with teams is to exclude some of that stuff but slowly introduce it and train junior developers on some of the concepts in the hope that I can push that knowledge forward.
Curious what others think of this dilemma and how they address it.
[+] [-] jbaudanza|5 years ago|reply
[+] [-] simon_mannes|5 years ago|reply
I'm only 7 years into my professional software engineering career and this really stuck with me. Over the last two years I had the honor to work with an awesome team on an interesting project, and yes, trust is the basis of exceptional teamwork.
[+] [-] datenwolf|5 years ago|reply
> 1. Beware of the Curse of Knowledge
I'd like to add, that knowledge can lead to "knowledge paralysis": The more knowledge and experience you have on a certain topic, the more problems and caveats you'll spot right away. Awarenes of those may prevent you from actually engaging in productive activity and instead tiptoeing around the problem at hand, instead of just implementing a "straightforward" solution (that ignores the 0.1% of corner cases, you know about, but won't have to care about).
This is omething I'm struggling more and more these days.
[+] [-] coffee|5 years ago|reply
This sounds amazing. I'm curious...how does salary change? Or does it change? How is all of this handled...
[+] [-] mr-wendel|5 years ago|reply
1. Learn to write specs
Call it an RFC, call it a PRD, call it whatever. Writing out a plan for any project taking around a week or more is always worth it. Use it to establish scope and priorities. Keep a "Questions" section that you whittle away at as you seek out feedback. Make the body a hierarchy of design tasks and implementation ideas. Track revision history and keep it up-to-date.
You now have a great way to get sign-off from peers + management, an execution plan, a task breakdown for ticket management and historical documentation on what happened and why.
2. Be terse
Is that email looking a little long? Write a "TL;DR:" section at the top and then see what you can delete. If it's nothing, leave the "TL;DR:". Otherwise you may find you've included a lot of intermediate thinking and people only need to know the conclusions.
3. When learning something new, keep a dedicated list of "this looks like magic!" items
Use your "down time" to research items on this list instead of refreshing your favorite news aggregator. Ask your peers and mentors about them. Notice when tangental issues come up and spend a few extra minutes seeing how they're related and how that might yield some easier answers.
4. When you want to ask for help... defer clicking "send"
Whether its an IM or email, write it up on the side first. Start with your question and follow-up with what you've already done to walk through finding the answer to save the person the effort of starting from step one or pointing out the obvious thing you overlooked. Often this will lead you to answering your own question. If not, still wait 15-30 minutes (if you can) before sending it and work on something else. In that time you're likely to think of something you overlooked and avoid interrupting anyone.
[+] [-] uppsalax|5 years ago|reply
Even if I am moving my first steps into the industry (I'm a simple trainee at a Tech-StartUp and MSc student) I've already experienced many times the first point. I think trying to keep your feet (and mind) on the ground, even when you have a huge expertise is fundamental in communication, teamwork and goals' chasing.
For example a friend of mine, graduated in one of the top programs in europe at Rotterdham Business School, has a huge expertise in the R language, he is able to manage data promptly at work, efficiently delivering in 2 hours what his colleagues do on Excel in the whole day. However he has big problems in communication here in Italy, he is not able to understand what other people with different background/expertise are asking to him precisely and this is becoming a huge issue in terms of career development.
[+] [-] YeGoblynQueenne|5 years ago|reply
The more I learn about smart people, the more I realise how dumb they are.
[+] [-] berkserbet|5 years ago|reply
[+] [-] aj7|5 years ago|reply