Ask HN: How is your company training you to become a better developer/engineer?
I’m interested in how companies create 10x engineers. To deepen the discussion, you can cover for example:
- What skills
- Training frequency
- How is your next set of skills decided? Is it personalized? Are you involved in the discussion?
- What are the biggest obstacles to your training?
151 comments
[ 3.8 ms ] story [ 248 ms ] threadAs hinted in my previous comment, I don't think they can and I am also not convinced that it would be beneficial to them if they could.
They need good engineers. That is achieved through hiring and compensation policies. Then, it is also beneficial to retain and keep engineers up-to-date through a level of training as needed.
the less effort exerted globally by the workers the less expectations will be placed on them by managers. God forbid people find their meaning outside of drudgery on their lords fief.
[0] https://www.youtube.com/watch?v=b2F-DItXtZs
To me, pairing is exhausting, so I don't like to do it too often but I almost always feel more than twice as productive and I feel like I am better able to dig into the hard stuff easier.
My previous company had bi-weekly presentations by some engineer on a technical topic they enjoyed.
I work for the so-called "software house". They keep on asking if I want to do a cloud cert yet they don't really provide any course materials nor allow me to take time off to focus on learning. This is a very common pattern for these certs and I've seen the same in other places as well; there's always someone who wants you to get that certificate but you're never really provided with anything to help you reach that goal. It makes it feel like the entire ordeal is pointless to begin with.
Recently the client I work for started moving to Kubernetes, which we did not use previously. It took my company 6 months to organize a Kubernetes course for us. The person who prepared that course was a relatively inexperienced engineer from an another team that never used Kubernetes in production. The engineer himself tried his best but in the end that person was not a very good teacher (which I feel is the natural outcome, this person was not hired to organize course work) and we never moved past the tutorial level knowledge-wise. Personally I got nothing out of attending these sessions aside from the liability of having to work on tasks related to Kubernetes (previously we didn't work on them as it was understood that we have no training, but now that we have "training" we are supposed to pick up that work). I feel like I was tricked.
Either way, they could have just paid an another company to get us a real course but they'd rather pretend they have competent devs rather than actually have competent devs.
Why?
Most of the training sessions I attended or used to happen in my organisation were on very general topics. All these topics can be easily learnt via any other medium like youtube.
Instead, I have seen pair programming or code-reviews making better engineers. The organisation used to change the pair programming partners every sprint making us understand new ways of working every time. Plus reading other's code in code reviews exposes you to new patterns making you better at writing code.
It is the people who make themselves 10x
> What skills
Currently focusing on the cloud.
> Training frequency
Whatever I want to outside working hours (expensed), 10-15 percent of working time for long term training (over months), 100% of working time for short-term training (say a 5 day course).
> How is your next set of skills decided?
By me and my manager. Long and short term trainings need to be approved by manager, but I never heard of anyone getting denied for that.
> Is it personalized?
> Are you involved in the discussion?
Yes, I need to find and register for the courses myself.
> What are the biggest obstacles to your training?
Lack of time. For AWS - corp policies are very restrictive so it's easier to bankroll my own AWS account for training, rather than use company's accounts.
Individual team members suggest trainings on a topic, and if enough people are interested they schedule a time and do it. We have book clubs, and regular developer discussion group. All of this is encouraged and on company time.
There are also more extensive multi day trainings and certifications I haven’t been part of.
We also have a monthly training stipend which accumulates.
Etc.
I’m expecting awesome results any time now
1. The experience
The experience with the consultants was really eye-opening. I will try to describe it below.
Since day one, without having much understanding of how and why we are organized, the consultants started seeing problems, and, oh what coincidence, they had the solutions for every-single-thing that they noticed. They tried to convince us, in no particular order, that our problems were:
- Not following Scrum well enough. That continued until we asked for specifics what part of Scrum we are not following well enough. Surprisingly, they didn't have a ready answer for that and then dropped it.
- Not following SAFE. Scaled Agile For the Enterprise sounded good to our C Suite, but the consultants played themselves by saying they can help us implement it. Our management, just like a gazelle seeing an encroaching predator, avoided the trap.
- Not having Agile coaches on a fulltime payroll. Guess who is an agile coach that can work fulltime for us? That was easy to see through, our C Suite will turn their nose at anything that implies spending more money, so they were naturally immune to that approach.
- Some Miyagi-Do level stuff about communicating better which was a bit fuzzy to me. I guess the Agile coaches have to...communicate better? One can think of that experience as a lesson, and that by communicating badly, surely on purpose, the agile coaches showed us the value of good communication! That is some black-belt level stuff!
2. Cracks begin to show
Things started souring in the 3-rd month, when our management started getting impatient seeing any results in performance. Occupying all your engineering teams for days each week surprisingly had the opposite effect on performance that our C-level hoped for. Then management also got wind of the agile coaches' vision of a "perfect Agile company". According to them, to be Agile (capitalization intentional), each of our teams needed to have:
- A Product Owner
- A Scrum Master (a dedicated person who ONLY does Scrum Master-ing)
- Agile Coach
- Team Lead (responsible for developers' growth)
- Tech Lead (responsible for tech decisions)
- Developers, if the budget allows
While we had only POs and Developers, with rotating Scrum Master role, with one developer being the Tech/Team lead. The prospect of having to hire more people to fill all these Agile roles spooked our C suite to such extent so they completely abandoned the whole Agile idea and let go of the coaches. And just like that, Agility was not spoken about since.
3. The results
Three months later, thousands of $$$ and people spending their time in meetings, the results can speak for themselves:
- we have spent thousands of $$$
- people spent their time in meetings
Based on what you wrote, I think you will see similar exciting results! Onward to Agility!
How my company is trying to deal with that is by creating a library of self-paced training modules maintained by software engineers, and facilities to help anyone do that. I'm not sure it's going to achieve exactly what the OP is asking about, but I think it's better than alternatives.
We also have a private Stack Exchange server, frequent tech meetups, internal support slack channels and a bunch of other ways to interact with internal platform teams that help quite a bit.
Still, you have to walk the walk and figure things out on your own at the end of the day.
When I've been through the interview process, it's been very obvious that I have strong backend skills but lack on cloud and DevOps stuff, so that's what I'm focusing on now.
>Training frequency?
As of now, most of my tasks are related to cloud and CI/CD and, to be honest, I'm enjoying it a lot, it's more fun than backend to me as there's plenty of new things to explore and learn. I even feel like I might switch from backend development to Developer Experience Engineer, exploring new ways to make development, testing, deployment and initial setup faster, easier and more enjoyable, since I like to think that I know how developers feel about our current processes and what can be improved.
>How is your next set of skills decided?
I just tell my manager that there is some stuff I'd like to learn and tell them what is it.
>Is it personalized?
Yes.
>Are you involved in the discussion?
I start it.
>What are the biggest obstacles to your training?
Sometimes, when I meet a new task I have no clue how to even approach it, I feel a bit overwhelmed and unmotivated, so I take my time preparing for it and asking around for initial problem study.
I know it's not very productive, but it's an enjoyable pace for me and my company promised me a raise if I get better at cloud, DevOps, Docker and AWS stuff while I'm on my probation.
The "best" engineer in the world would probably tell you that "the only thing that they know is that they know nothing". They may also say that the most valuable thing that they have learned over their career is humility. There is always going to be something new and shiny to learn, things will always be breaking around you, a fake prophet will push today's ideology to sunset yesterday's. The only thing that you can do is to always be resourceful, to grow holistically as a person, and help others grow as well. Avoid any company that tries to distill these virtues inside banal presentations and check-the-box training sessions. It is better to ask an unassuming looking person inside the company if they have grown as a person, who helped them, and whom are they helping do the same. Good luck!
It was from a study that showed vast differences in performance across software engineers, up to 10x.
The study has been criticized somewhat since then but I think the critics miss the point. Regardless if it is 2x or 10x, or somewhere in between, these differences do exist.
For example, we had slow query performance in Postgres. I (a 1x engineer) couldn't optimise the query, so I suggested building out a caching layer, with an estimate of 2-3 weeks. My colleague (a 10x engineer) used a window function that took about an hour.
Perhaps from their perspective, I'm a -10x engineer.
In case anybody is curious, here’s the study from 1968:
https://web.eecs.umich.edu/~weimerw/481/readings/productivit...
They claim that the best are 10x better than the worst but only 2.5x better than the median. Additionally programmers from the same organizations had very similar performance. I.e. there probably isn't a 10x difference in performance within your company.
The book claims similar distributions when you measure many kinds of human performance, so I wouldn't be surprised if there were many studies that replicated the general idea.
Myself personally, I don't think it does, not because some people aren't naturally better at programming than others, but because at some point the important decisions are unrelated to programming and are more about systemic decisions at a wholistic level.
Honestly I’m quite tired of this false humility norm. Seems to me it’s mostly about redistributing the fruits of common labors from those that focus on the craft and try to improve their productivity, towards the socially focused “humility experts”. I much prefer working with cocky 10x engineers rather than these humility policing 1x ones…
I wouldn't call myself that if I were speaking to a junior developer and helping him with something that's difficult enough to sap his confidence.
You also have to take the Dunning-Kruger effect into account, where most developers aren't able to evaluate themselves correctly. In our work we have a tendency to view thing as "right" and "wrong". I often find people with a few years of experience to be the worst. They have enough experience to recognise that they are more knowledgable than juniors, but lack the overall picture.
Some even come out of studies this way, because they are used to being the smartest in their class and have built up their egos. "Why is the old shitty code written this way, they must have been stupid? We need to rewrite it in the framework I read about in the blog last week". Only experience will teach them that things are not that simple. If they are not exposed to the right working environments in their first jobs, they will spread this negativity for years until they (hopefully) grow as persons.
Pro tip: If something looks unnecessarily complex, there may actually be a reason for it. In the case where you need to rewrite/refactor working stable code, don't try to negatively push down others to enhance your own feeling of superiority. Keep the arguments as objective as possible. If you have tracked the code to specific individuals, at least talk to them in private first to get their input instead of assuming you know best.
This is exactly what I'm tired of: Because other people are assholes with big frail egos who do not understand their place in the world... I have to change? No, they have to change.
Putting this on me just glosses over and prolongs the real problem: That a lot of people with frail big egos need to realize they are not all that and come down to earth.
More generally: Your perceived correlations are not necessarily causal relationships.
This is my strength and I'm absolutely better at it than most. There's lots of things I'm completely inadequate at, this aint one of 'em.
In reality if you won’t shout about how great your work is how can you expect anyone else to care about it.
It is a matter of where you focus your humility.
Your accomplishments and deliveries? Absolutely market how they are 10X impacts than the norm. No need to label them "10X" of course. Point out their impacts, and the impact craters on problem spaces label themselves. And thereby you get labeled.
How much you rely upon everyone around you and they in turn rely upon you? Absolutely show humility here. These days, 10X impacts don't happen frequently until entire teams are coordinating together over long periods of time.
The knowledge tree in our industry is effectively infinite in all directions now. No matter how broad your reach, there are always more topics you haven't been exposed to. No matter how deep your "T" stem areas, there is always more depth to plumb even if you are at the cutting edge, for the fundamental limits of physics is the only true bottom of that trench.
Humility is absolutely essential when offering to help others and organically receive help from others to mutually cover everyone's gaps across this functionally infinite canvas of knowledge when taking down objectives together.
I don't know... Humans have a very strong tendency to promote cultural norms that will make them successful. So the socially focused "humility experts" want to make the game about humility. One of their IMHO less ethical moves is to sabotage others who do not want to play their game.
I'm good at writing software and leading software teams. I want the game to be about that: the software. I have no problem what so ever with people being proud of their work. I'm not going to refuse to help someone because I don't think they are humble enough. It would never even cross my mind. It would defeat the purpose: creating great software.
Oh, those are straight up assholes in a different clothing of the week. Yeah, once I identify one of those, I route around them if I can, or they find that my teams and I will only work with them on a very formalized, documented in the open, by the book, unfailingly positive and polite basis. If I have to, the juniors I advise will see their work that is unavoidably interfacing with such people championed by other managers and me.
It vastly slows down the delivery velocity around said person, but I've found no other solution when I'm forced to work with them as they're utterly toxic to work with otherwise. Such a person will find the Nash equilibrium adjusts the more they give up said behavior, but in my experience I've never seen one of these types turn completely around (but that might just be a function of only consulting and not sticking around long enough to find out).
i’m curious if you’re being facetious, though, due to a possible resentment of your co workers. IF you’re doing that, remember you’re just being paid to do YOUR job. management knows who the performers are.
What kind of resentment would there be towards my coworkers? I am not sure where feelings would be coming into play at all, let alone ill feelings.
I mostly integrate with other teams' services. Most of my time is talking with them (in "Meetings") about their API and reading through their documentation.
Code is like 10% of my week, maybe 20-25% if I'm starting with a fresh service.
It's amusing that we can integrate with open source APIs without any trouble, even when there is often much more complexity involved, without ever talking to the person/people behind it, but as soon as its within a single organization it becomes a game to find pointless busy work to fill the hours.
This just tells me that the engineer in question is very good, but also has imposter syndrome.
Trainings don't work. What does work is pair programming but you have to do this effectively. Say you have 3 buckets, frontend, backend and infrastructure. Ideally, you want to pair someone who has very full infrastructure and backend buckets, with someone who has an overflowing frontend bucket. Mix and match. There's no value in pairing two more backend oriented engineers together.
There's also no value in categorizing things in frontend and backend, if you just have a frontend engineer that throws things over the hedge to the backenders garden, you're going to have a shit shoveling contest and this doesn't work. Of course, you should still have people specialized in certain domains, but you should try to share knowledge within your team as much as possible and try to broaden's people experience instead of having people work on their own little islands. Pair someone with a backend background on a big frontend ticket with an experienced frontender and before you know it you'll have two full stack engineers that'll possibly grow to become a "10x" or whatever that means.
Code reviews are critical and it's important to have someone in your team that carries a big stick and isn't afraid to use it. This is a sensitive thing I've noticed, I've worked at companies where I wasn't the only 10x engineer, and the code reviews there were a joy because I was getting very valuable feedback. It wasn't so much that my code was wrong, but more something like `{} as MyInterface` could also be written as `<MyInterface>{}`. There were a lot of style related comments. What I notice in my current team is that people feel like this is unnecessary, but I always felt like it is valuable when another engineer suggests something like "maybe you could abstract this?" because it introduces a bigger picture that I may not have thought of before. It's very loathsome to carry the big stick, but I feel like if I dont, we're going to go back to the old patterns of not writing tests, not thinking about architecture.. Those kinds of things.
The best bet for both parties would be they find places “where they belong” - if you consider yourself 10x ie the smartest person in the room, you need to seek a better room for yourself where that’s not the case.
So I don't see much benefit in training, what works much better is learning by example. Put junior engineers in a team with a 10x engineer and if they are open to it, they can quickly acquire the same mindset. But ofc this only works if the 10x engineer is a good tutor and coach as well.
Set the expectation right, treat people like adults, expect that the person you are paying and employing as an adult engineer is an adult engineer capable of solving their own problems, and they will figure out how what they need to do to meet expectations and acquire the knowledge they need, whether that be training, or just google, or just looking at existing code.
In my entire career (spanning 20 years by the year, 16 years of active time), I've only met one engineer who astonished me with his prodigious amount of _correct and clean_ output. But the downside was that engineering was his entire life; you couldn't hang out with him, because all he ever wanted to talk about was engineering.
There's a tradeoff for that kind of output.
* Providing us the training and paying for a cloud vendor certification
* It’s a small company so team discusses all major tactical decisions
* Providing me the opportunity to implement and document a new but super fast approach to architecture that I have developed over the past three years in a personal project
* This is only the second time in my career that I am engaged all day (been in the corporate world nearly 20 years). In prior jobs I went to meetings and maybe did 1 hour of work a day. That was either because task assignment was in competent or because they were not training developers which me a 10x developer only because I do work on personal projects outside the office
- my company is using DataDog and they offer us training on that. Well I don't care much about DataDog; I care more about how metrics work and what's behind the curtains (e.g., time-series dbs). Chances are that DataDog will be gone soon or, most probably, it won't be used when I switch companies. So, I prefer to focus on non-hype stuff
- same for specific frameworks we use at work. In one of my past companies we were using Laravel. They offered us training on Laravel... but I just couldn't care less. I don't use Laravel anymore (not even PHP). I would have preferred trainings on more agnostic stuff like architecture/design/algorithms
And like this, tons of similar examples. So, the way I become a better engineer is by studying by myself mostly during working hours but also a bit during my own free time. I read "the classics" (i.e., books every software engineer should read), I keep myself updated with releveant technologies and work on personal projects to solidify my knowledge. It's a win-win for both myself and my current company (even if my company doesn't realize).
How do professional sports clubs create 10x athletes? I expect the answer is that they don't. They seek out 10x athletes who were most likely born with certain qualities that allow them to stand out above the typical player. It would be a lot simpler for them if they could simply choose any person at random, put them through a training program, and output a star athlete but the world does not appear to work that way.
I imagine engineering isn't a whole lot different.
Seriously, though, even if the code itself has lots of room for improvement, the product is great and the team is competent and laid back; they trust me to take my time and do the right thing, and aren't breathing down my neck to get features out by end of sprint.
So give me the spaghetti code base with a non-toxic work environment where everybody is dedicated to incrementally fixing and improving it, any day.
Biggest obstacle; time/energy. 40 hours with 10 hours a day invested in the job leave me with zero motivation to further do training. Risking burnout here, I need to get away.
My employer current and past has no problem teaching me what I need to know to do my present job but zero involved in progression, that's 100% on me. Obviously that's their prerogative. They all do generally pay for things I take electively, I just need to figure out what I want to do and figure out when to do it.