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.
That's what makes the difference. And no company can make you like the software you're making, to be disciplined if you don't train yourself so and to genuinely like and enjoy what you produce. It'd be equivalent to brainwashing.
So that may be a limiting factor even when your work ethic is high.
You might have ADHD but you can also adjust to it and work around it. Don't call it quit until you literally exhaust everything you can.
Most can't really work around it in the sense I think you mean.
If everyone else prioritizing and doing work us like walking, for someone with ADHD it's like walking underwater.
Not only is it much harder but:
- it looks and feels ineffective
- you have to stop progress to come up for air iften
- when comparing to others it's easy to feel lazy and get demotivated
I'm kind of in the same boat. I don't really like the open-source software I'm paid to develop. Some combination of that, my ADD, and maybe burnout, make it really hard to plug away at developing that software. I have no doubt the ennui seriously dings my productivity.
Then a few weekends ago, I started working with some open-source software that's adjacent to my day job. I get to work at my own pace, focus on the parts that interest me, etc. I'm really enjoying myself.
I see two possible benefits to this weekend activity:
(1) It's helping me to enjoy programming again.
(2) If I'm really lucky, the knowledge and/or software I'm developing will become relevant to my day job. I think that would make my day job a lot more fun.
A lot of truth here. Many times it's nigh impossible to work at 8am, but at 2pm I can nearly always be productive.
This works for some things but not all for me. Also there is no universal add or adhd experience.
For me the difference between work ethic on adhd meds versus without is night and day.
I'm not lazy without them, it's just all of my energy can get consumed by a million other things than the task at hand.
For me, the way teams are structured where I worked there where 2 sides, build and support.
Build focuses on new builds. One project, until it's launched. That didn't work for me.
Support is projects that are already launched that need new things built out, maintenance, etc.
New builds is usually backend dev, front end and one that can do a bit of both. Support usually has a dev per 5 clients.
I loved being in the support side and floating to new build as needed for my expertise. While most other teams have a dev per 5 clients, I was able to automate parts of the maintenance and by myself I handled 35 clients.
I worked with the leadership at the company. I was able to create my own department afterwards. I had the ears of everyone.
With 35 clients, I was switching all the time. Priorities shift. Goals shift. It was great for my ADHD brain. Blast some fast paced music and start my day.
-----
Find what works for you. Do you need to switch it up often? Do you need things written out and longer projects? How does your ADHD brain work?
[0] -https://dev.to/tigt/making-the-worlds-fastest-website-and-ot...
But it's worth mentioning that a company can make you dislike the software you're making.
from https://en.wikipedia.org/wiki/Kurt_von_Hammerstein-Equord#:~....
I don't think that anyone who believes in the "10x engineer" (myself included) thinks it has anything to do whatsoever with how much they work, or their attitude toward the work. "Work ethic" suggests that it's about how much effort they choose to put into it, and that's nothing to do with it. 10x engineers will do more per hour than median engineers, whether they work one hour or ten in a day.
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.
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.
I strongly believe if you want to make it in this industry you have be self motivated to educate yourself and develop relationships with potential mentors. Nothing will come from your employer.
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.
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.
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!
The difference between them and a run-of-the-mill external psych is that they can actually influence company policy (for real - hiring them was the CEOs idea). They also know the company and the people there, which helps a lot in understanding people's chemistry and habits.
In addition the company reimburses for all external training courses taken which you can even in some way say are connected to what you are doing - or want to do at work.
Does this make everyone 10x? Nope. Has it made a huge difference in the way I work? Yes.
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.
Everyone who is a manager actively makes independent contributions for a not-insignificant portion of their work-week.
So, when we have 1-on-1s with them, we can actually discuss improvement avenues from the same vantage point. Not some spreadsheet pushing manager who has no clue how to measure engineer-productivity or performance.
When they do code reviews, their comments serve as an important learning opportunity, pointing out good practices/conventions, etc.
And finally, when you disagree, it's backed by the validity of your points as 2 engineers, rather than their authority as a manager vs you, their direct report.
So, it's sometimes nice to have periodic validation that you're keeping true to the course / indication that you need to make a few minor adjustments, etc. That's on your side.
From your manager's side, if they find something isn't working, they don't need to wait 3/6 months to bring it up at which point there isn't much you can do to get back the lost productivity.
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.
* 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
As 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.
It is the people who make themselves 10x
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.
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.
The value of a person engaged in software development is highly context dependent. In the last year as an "engineer" in my previous role, I made a single code commit. A one line configuration change as part of an ops rotation. When I announced I was leaving, my supervisor (and his supervisor) was sad. They threw me a party with a customized cake. How was my contribution being measured? I wasn't managing people. I wasn't coding. But I had "built" multiple products.
Someone once asked me "how do you explain to your parents what it is you do at work?" I replied "I can't even explain it to my boss."
People regarded as 10x in one situation will enter another situation and appear to fail miserably.
> 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.
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.
- 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).
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.
It's one of those things that is so rare that there is little in common across actual 10xers. To cherry pick any aspects of "common" 10xer backgrounds and try to apply these to "grow" a 10xer makes about as much sense, in the business domain, as finding out what Warren Buffet eats for breakfast and then doing the same expecting some kind of results-- or maybe wearing turtlenecks like Steve Jobs (people have tried).
It it far more realistic, I think, to simply strive-for and train-for valuable skills/capabilities, to seek out effective people around you and learn from them at a "ground-level" and solve problems collaboratively and thus learn their approaches, developing an intuition of how to proceed against challenges.
Here's my reasoning why the reverse would work also: Most comments on here that acknowledge the 10X programmer is a real phenomenon agree it's not about speed of writing but understanding the business's needs and finding the optimal solution, not coding the obvious one 10X as quickly. That requires a workplace where people feel safe thinking outside the box.
Much of this idea comes from this speech by John Cleese: https://www.youtube.com/watch?v=Pb5oIIPO62g
Then going from Groovy to Kotlin (using types in your advantage, functional-style where it makes sense, IDE comprehension of code, fear-less refactoring).
Now we are using Elm to replace some brittle React/Litelements/jQuery mess (sum-types, strong typing, currying, etc.)
Also I believe we should regularly discuss bad code examples, code style improvements and evolving the processes. We do this in a "retro" session at least once a month.
One of the best thing I learned is to accept to be a "bad programmer", hence I like strong typing, defensive coding styles, and smart IDEs.
My previous company had bi-weekly presentations by some engineer on a technical topic they enjoyed.
"great teams make great engineers", not vice versa
https://www.youtube.com/watch?v=XppRCB99djw&list=PLuAItjWV4p...
How do you think a team of ordinary (1x) engineers will function if you add a 10x engineer to it?
I'm my case it was like putting a car driving 100 mph where the speed limit is 10 mph. A disaster.
I think that a 10x engineer could work alone in isolation.
Base in my experience a 10x engine would also not function in a team of other 10x engineers. You need to have complete disregard for what others think and do if it's anything like my experience.
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.
After having looked for opportunities for a while, I suspect being independent/in a co-op, or at least in a very employee oriented/owned shop is required to take care of your own long term development.
Right now our strategy is some combination of mentoring/pairing time, teaching concepts and how to apply them, encouraging devs to take ownership of their work and rewarding them by having them present their work to clients.
Is it working? Staff seems generally happy with that way of doing things but we aren’t measuring it.
Will continue to look for ideas here.
Today? You need 5 years of specific tools to get a job. 10 years of total experience. There are exceptions as always..
They don't. All the ones I can think of appeared before getting paid. I'd hesitate to say they are born but they're certainly not made in the corporate world.
Also to answer your first question: my company isn't.
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.
It's about 10 years late, but it's an improvement...
2. let people have time to spike WHILE working