[foz]

It's hard to name one skill, but I'd put these into a single topic: the "soft skills" for becoming a more effective senior engineer.

Learning how to pair program effectively, and pass along skills to others. Performing great presentations and demos, and writing about your work. Being able to avoid complexity by finding simpler solutions. Separating yourself from your code and being open to criticism. Studying how goals, objectives and tactics relate to actionable tasks a software team needs to execute on. Becoming better a time management and prioritization, and delivering value faster.

None of these are very technical skills, but they require a lot of practice and a ton of patience.

[jasonpeacock]

Similarly, learn how to be a "force multiplier". Don't be the 10x engineer, but instead be the 10x multiplier.

How do you increase the quality & output of your entire team/org/company? Better features, fewer bugs, faster releases, etc. Learn what it takes to effect that change, and then learn how to make that impact wherever you are.

[1091298301]

Leave them alone? I've always worked in "teams" where 1-3 workhorses made everything happen; the rest was talking, spinning intrigues and inventing new workflow procedures (which slowed down and annoyed the workhorses).

[jknoepfler]

Not a sustainable model, or a formula for growth. If you genuinely think this fire your time wasters and raise your hiring bar.

If you don't invest a piece of your work week mentoring juniors, you're a lot less productive than you could be.

[candiodari]

Have you ever seen a product manager or "the meeting guy" train juniors ? That doesn't even make sense, as you haven't hired those juniors to do either product management or "stakeholder management" or ... whatever the next fashionable term will be, so they simply can't provide the training that is needed.

At least where I work, the "workhorses" are the ones training the new guys.

[aries1980]

I did and I was one of the mentee as an engineering lead. All I needed is to attend on meeting and listen or support the PM, but it was invaluable to see how to reason, convince stakeholders, gather requirements and objective feedback, and how not to give a fig to the emotions.

[aries1980]

Not every problem has to be solved in team fashion and not every member of an organisation has to fit in a hiring pattern. Also there are “brilliant jerks” or people with out-of-fashion worldview. These people could have their place in an organisation. Clearly this is a leadership challenge, but hey, leaders should learn hard and be great as much as their engineers.

[jasonpeacock]

Those "workhorses" negatively contribute to your bus factor[1], they're a risk that needs to be eliminated.

That doesn't mean you have to eliminate the workhorses, but you need to convert them from being 10x engineers to being 10x multipliers.

This is the valuable and essential element of personal growth that I'm espousing - teach yourself how to multiply the team's output.

[1] https://en.wikipedia.org/wiki/Bus_factor

[Bahamut]

That effectively has happened at me at work - I volunteered to become a lead engineer, and have been thrust mostly into management. It has been a very enlightening experience, as I no longer am solving the difficult technical problems on a day to day basis (I maybe will solve one abnormally difficult problem every week), but I am now judged on the productivity of my team - I dropped my coding to near zero and focused on the soft skills & using my technical ability to help craft approaches for my team members to get to a more consistent level of productivity.

While my outsized code productivity was decreased to near zero, my team is moving faster, which benefits the company over the long term, as well as me being able to gain the skill s needed to help mentor people in concrete fashion to become better engineers.

[nvarsj]

> That doesn't mean you have to eliminate the workhorses, but you need to convert them from being 10x engineers to being 10x multipliers

By stopping them from producing things of value? How does this make any sense. It's the peter principle all over again.

[jasonpeacock]

Let's assume you have 3 engineers, one 10x and two 1x, their total output is:

10x + 1x + 1x = 12x

Now you convert that 10x engineer into a 10x multiplier, and let's assume he doesn't actually do real work anymore because he's helping everyone else be more productive:

0x + 10x + 10x = 20x

He may no longer be doing any work, but the rest of his team is more productive and significantly outstrips his own individual output.

That's some very impressive made-up math!

Obviously the real world is not so simple, but the effect is the same. There's the engineer that cranks out a crazy amount of code and nobody can keep up, and then there's the engineer that helps everyone else crank out more code - now everyone is learning and increasing their output. Which would you rather have on your team?

[loop22]

Make a 10x engineer help everyone else be more productive all day? Sounds like an effective way to lose that engineer.

[olavk]

So how do you turn a 10x engineer into a 10x multiplier?

[clumsysmurf]

Sound like a 'distinguished engineer'. Some good thoughts about there here:

"On the Myth of the 10X Engineer and the Reality of the Distinguished Engineer"

http://redmonk.com/fryan/2016/12/12/on-the-myth-of-the-10x-e...

[avaer]

If you really _are_ a 10x multiplier on a team, you should immediately quit and run your own show, because there's otherwise no chance you're being compensated remotely fairly -- nine times the sum of everyone else's wage.

[groby_b]

If money were the only meaningful thing in life, you might have a point.

In the meantime, many of us are happy enabling other people to be more productive and making an amount of money that can certainly be described as satisfactory.

But even if you want to maximize salary, being a 10x multiplier on a team in a large company is a very different thing from running a company. (And running a company is a very different thing from necessarily making insane amounts of money)

[mahyarm]

So you mean join the developer tooling & infra team?

[JeremyMorgan]

I came here to say this. So many of us focus on the technical advancement only. But learning to work with people becomes more valuable in the long run.

As far as specific tech, my crystal ball is a bit fuzzy right now but AI seems a decent bet.

[vram22]

Interesting list.

>Being able to avoid complexity by finding simpler solutions.

This is one of the most important ones, IMO. Sometimes it may also mean reducing the size or scope of the problem itself - because YAGNI (where Y is the customer), or AYRSYNI (Are You Really Sure You Need It - TM me :). Seen it done by my managers a few times, and done it myself a few times (sometimes successfully, sometimes not), as a consultant.

https://en.wikipedia.org/wiki/You_aren't_gonna_need_it

https://blog.codinghorror.com/kiss-and-yagni/

Also, googling for links for YAGNI, TIL about:

https://en.wikipedia.org/wiki/MoSCoW_method

:)

[vram22]

Also, on a related note, since it is mentioned under the MoSCoW method (above), has any one tried timeboxing?

https://en.wikipedia.org/wiki/Timeboxing

I had read about in a book by Steve McConnell, IIRC (maybe his book Rapid Development), but did not get a chance to try it in a real life project - yet.

[tracker1]

I wasn't aware of the term, but I often give myself up to 2x the estimated time to do something... once I hit 150%, I'll do something less elegant that can move things forward and punt the issue for now.

Perfect example, starting on a new SPA, wanting to use latest/greates React/Redux/Webpack/Babel tightly coupled to a Node API latest Koa and it's ilk. For the life of me, could not get the Webpack dev server bits to work with Koa. Spent about a day and a few hours on it... finally decided to run the node server on a separate port, and have the webpack dev server set to reverse-proxy to it. I have no current plans to run websockets on my backing service, so it works for now, but not the integration I wanted, the way I wanted it.

To me, it's just being pragmatic with my time... I was explaining to a friend who asked, "were you pressured into these time constraints...?" and my response was no, it's just I wasn't going to delve into a week+ of work to get things the way I want only to provide minimal value, while the larger OSS dev community will likely provide a better solution before I can circle around to it.

I love OSS, I participate when/where I can, and appreciate all that everyone does. If you're working on something that can be separated out, that isn't a core to your business, why not put it out into the world and save someone else some time down the road. I mean a lot of things are of varying quality, but if they provide value and save myself or someone else time, I'm all for it.

Where I feel bad are the projects that start off small and hit a critical mass where the support exceeds the time/expense to support something. It's always a matter of reaching a pragmatic balance to one's efforts.

[vram22]

Yes, that is something like timeboxing, except they don't have a 1x - 1.5x - 2x thing, just 1x.

[dasmoth]

This does seem to be the mainstream view at the moment.

Any thoughts on the best opportunities for tech-oriented people who don't want to fit themselves into teamwork-focussed environments?

[closeparen]

What are some software projects you admire that were created by one person without teamwork?

I'd argue our field is past the point where writing any unqualifiedly impressive project is within reach of a single person, no matter how talented.

[aianus]

> What are some software projects you admire that were created by one person without teamwork?

Bitcoin, Minecraft, Bittorrent, Spark, american fuzzy lop, Tarsnap, PGP, and many more.

[closeparen]

Bitcoin: nope [0]. Bittorrent: there's a huge ecosystems of clients written by different teams of people. Spark: do you mean Apache Spark? It has many contributors [1]. Tarsnap: is convenient plumbing wiring up S3 and the academic cryptography literature, neither of which are solo efforts. PGP: its most important manifestation is probably GnuPG, which also has several contributors [2]. Minecraft: Mojang has 47 employees [3]. I doubt Notch is the only person with code in Minecraft.

You do have a point that solo brilliant engineers can start projects that go on to have massive impact (cough Linus Torvalds), but once those projects have reach, they tend to have teams.

[0] https://github.com/bitcoin/bitcoin/graphs/contributors [1] http://spark.apache.org/committers.html [2] https://www.gnupg.org/people/index.html [3] https://en.wikipedia.org/wiki/Mojang

[aianus]

They were all 'created' by one person without a team. They're now maintained and perhaps improved by teams but that's a different story.

[tracker1]

But initial implementations are a single person, and yes, once they have greater adoption do grow... that said, there's still a lot to be impressed by in initial release.

The most recent one that comes to mind are redux + redux dev tools. Though definitely have grown since initial implementation, it was one of the more impressive things I've seen recently. Second in my mind is git itself.

[clay_to_n]

All of his points except the first two are even more valuable if you don't want to work on a team.

When working solo, there's nobody to insulate you when your soft skills are lacking.

[tracker1]

You can always try to work on projects, or portions of projects where your interactions can be minimized... You can be a contributor without having to have constant/heavy team interactions.

There are aspects of all of the above I tend to appreciate greatly, it really just depends.

[paulcole]

1. Start your own 1-person business.

2. Work on resolving whatever issues led to the dislike of teamwork in the first place.

[garysieling]

Agreed. Some of the tech-oriented business conferences have talks I've found fairly helpful. E.g. talks on sales can be helpful, even if all they do is help you communicate better with other groups.

Some examples: https://www.findlectures.com/?p=1&type1=Conference&talk_type...

[j_s]

See: Programming Beyond Practices by Gregory Brown released last year

https://www.amzn.com/dp/B01LYRCGA8

[skyisblue]

Are there any good books you can recommend that will help a software engineer's soft skills?

[foz]

"Managing Humans" by Michael Lopp made a huge impression on me and my career. https://www.amazon.com/Managing-Humans-Humorous-Software-Eng...

Also, "The Phoenix Project" which IMO is a groundbreaking work on how to make IT/business more effective (and the start of the DevOps movement). https://www.amazon.com/Phoenix-Project-DevOps-Helping-Busine...

Even if you're not a manager, both books are very approachable and packed with great lessons about how improve and better work with people, teams, and business.

[pieterr]

Peopleware. https://www.amazon.com/gp/aw/d/0321934113/