5 ms·

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 progr

by foz 10y ago

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.

JeremyMorgan 10y ago
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.
jasonpeacock 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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 10y ago
        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.
    - deleted 10y ago
      [deleted]
    - aries1980 10y ago
      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 10y ago
    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 https://en.wikipedia.org/wiki/Bus_factor
    - deleted 10y ago
      [deleted]
    - nvarsj 10y ago
      > 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 10y ago
        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 10y ago
        Make a 10x engineer help everyone else be more productive all day? Sounds like an effective way to lose that engineer.
- clumsysmurf 10y ago
  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-engineer-and-the-reality-of-the-distinguished-engineer/ http://redmonk.com/fryan/2016/12/12/on-the-myth-of-the-10x-e...
- mahyarm 10y ago
  So you mean join the developer tooling & infra team?
- avaer 10y ago
  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 10y ago
    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)
garysieling 10y ago
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_l2_Conference=Business https://www.findlectures.com/?p=1&type1=Conference&talk_type...
j_s 10y ago
See: Programming Beyond Practices by Gregory Brown released last year https://www.amzn.com/dp/B01LYRCGA8 https://www.amzn.com/dp/B01LYRCGA8
vram22 10y ago
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://en.wikipedia.org/wiki/You_aren't_gonna_need_it https://blog.codinghorror.com/kiss-and-yagni/ https://blog.codinghorror.com/kiss-and-yagni/ Also, googling for links for YAGNI, TIL about: https://en.wikipedia.org/wiki/MoSCoW_method https://en.wikipedia.org/wiki/MoSCoW_method :)
- vram22 10y ago
  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 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 10y ago
    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.
dasmoth 10y ago
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 10y ago
  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 10y ago
    > 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 10y ago
      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 https://github.com/bitcoin/bitcoin/graphs/contributors [1] http://spark.apache.org/committers.html http://spark.apache.org/committers.html [2] https://www.gnupg.org/people/index.html https://www.gnupg.org/people/index.html [3] https://en.wikipedia.org/wiki/Mojang https://en.wikipedia.org/wiki/Mojang
      - tracker1 10y ago
skyisblue 10y ago
Are there any good books you can recommend that will help a software engineer's soft skills?
- pieterr 10y ago
  Peopleware. https://www.amazon.com/gp/aw/d/0321934113/ https://www.amazon.com/gp/aw/d/0321934113/
- foz 10y ago
  "Managing Humans" by Michael Lopp made a huge impression on me and my career. https://www.amazon.com/Managing-Humans-Humorous-Software-Engineering/dp/1484221575/ 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-Business/dp/0988262509 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.

by foz 10y ago

JeremyMorgan 10y ago

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.

jasonpeacock 10y ago

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 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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.
  - deleted 10y ago
    [deleted]
  - aries1980 10y ago
    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 10y ago
  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 https://en.wikipedia.org/wiki/Bus_factor
  - deleted 10y ago
    [deleted]
  - nvarsj 10y ago
    > 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 10y ago
      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 10y ago
        Make a 10x engineer help everyone else be more productive all day? Sounds like an effective way to lose that engineer.
clumsysmurf 10y ago
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-engineer-and-the-reality-of-the-distinguished-engineer/ http://redmonk.com/fryan/2016/12/12/on-the-myth-of-the-10x-e...
mahyarm 10y ago
So you mean join the developer tooling & infra team?
avaer 10y ago
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 10y ago
  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)

garysieling 10y ago

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_l2_Conference=Business https://www.findlectures.com/?p=1&type1=Conference&talk_type...

j_s 10y ago

See: Programming Beyond Practices by Gregory Brown released last year https://www.amzn.com/dp/B01LYRCGA8 https://www.amzn.com/dp/B01LYRCGA8

vram22 10y ago

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://en.wikipedia.org/wiki/You_aren't_gonna_need_it https://blog.codinghorror.com/kiss-and-yagni/ https://blog.codinghorror.com/kiss-and-yagni/ Also, googling for links for YAGNI, TIL about: https://en.wikipedia.org/wiki/MoSCoW_method https://en.wikipedia.org/wiki/MoSCoW_method :)

vram22 10y ago
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 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 10y ago
  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.

dasmoth 10y ago

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 10y ago
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 10y ago
  > 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 10y ago
    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 https://github.com/bitcoin/bitcoin/graphs/contributors [1] http://spark.apache.org/committers.html http://spark.apache.org/committers.html [2] https://www.gnupg.org/people/index.html https://www.gnupg.org/people/index.html [3] https://en.wikipedia.org/wiki/Mojang https://en.wikipedia.org/wiki/Mojang
    - tracker1 10y ago

skyisblue 10y ago

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

pieterr 10y ago
Peopleware. https://www.amazon.com/gp/aw/d/0321934113/ https://www.amazon.com/gp/aw/d/0321934113/
foz 10y ago
"Managing Humans" by Michael Lopp made a huge impression on me and my career. https://www.amazon.com/Managing-Humans-Humorous-Software-Engineering/dp/1484221575/ 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-Business/dp/0988262509 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.