
As a software engineer, what's the best skill to have for the next 5-10 years? - programminggeek
http://brianknapp.me/software-engineer-best-skill/
======
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.

------
stupidcar
If you're a coder, and you have a job that lets you code (as opposed to
sitting in a lot of meetings), then you already "paint every day". Side
projects can be a useful way of learning new technologies, but if you're
already spending 7-8 hours a day "painting" in work, how much extra skill will
you attain doing more in your spare time?

I'd argue that you are better off doing anything _but_ programming in your
spare time. For example, learn some artistic skills, such as actually
painting, or drawing, or playing a musical instrument. Or master a sport, or
some other physical skill like woodworking.

Don't devote every hour of your life to just one thing. You already spend a
third of it programming. That's enough. Step away from the computer and become
a more rounded human being.

~~~
stygiansonic
In general, I agree with this. But sometimes, one's job doesn't provide an
outlet for one's passion. It could be because the technology is old, the
libraries/tools are out-of-date/internal-only or simply because the work feels
like a grind and doesn't lend itself to creativity.

In this case, there could still be room in engaging one's creative side
through a side project. The key is that a side project like this shouldn't
feel like "work". There's no use cargo-culting the side project craze if it
doesn't flow naturally.

For example, I have a friend who's currently working on a home automation
project that involves significant programming. I can tell it brings joy to his
life, the same way that painting would to an artist. Maybe this doesn't make
him more "rounded", but what's the difference? When I see him talk about it,
his eyes light up with the same passion I see from those in the traditionally
"creative" fields.

In the same way, I love spending time using Jupyter Notebooks/Pandas to do
rudimentary data analysis. It's fun, and I've learned a ton, some of which has
come back to help in my day job.

~~~
downboy
Exactly this. I grind on a massive codebase everyday and the time and risk
involved in migrating to new tech would be far too great. Going home and
spinning up a new project in some new language/framework is the only option.

~~~
tracker1
8 years ago, I was working in a pretty massive codebase... I did two major
refactors (both going into the wee hours of the night, so I could get it done
without conflicting with others)... one was changing all date-time
communications as well as ensuring all dates in the DB were UTC. The other was
refactoring all of the logging within an application in the client and server-
side.

Both times consisted of intentionally breaking things and fixing everything
that was broken in the new way. Both times I was jokingly referred to as the
"king of refactoring." After some relatively bad experiences late last year, I
was offered the job I have now working with a few of the people I worked with
then, based on that experience.

You don't always have to be afraid to make a sweeping change, but you should
have a plan, and should try to execute with minimal impact on others. The
date-time one was triggered by having to drive an hour into the office, at 1am
because of a bug in a deployment update... in the end, it was easier to rip
out and replace with something more consistent.

Also, there are times where you can break something off into something that
can use newer tech... such as a minimal node api connecting to a search
database that's feed updates by another mini service that replicates data from
an sql db...

Try to dedicate a portion of your day/week to exploring how new things can
provide value... get it done. As Admiral Hopper said, "it's easier to ask for
forgiveness than permission." Sometimes in the face of contrarianism, it's
easier to "just do it."

------
thunderbong
Typing.

By far the most under-rated and the most useful skill to have as a programmer.

When I seriously started programming, I spent one hour every day for 30 days
on typing using one of those many typing softwares.

The first thing I noticed was how much less thinking I was doing with regard
to my typing. I didn't have a part of my brain guiding my fingers any more -
the fingers already knew. The other thing I noticed was that I wasn't typing
by characters, I was typing by word.

With these two things I was already able to write programs faster.

But the other things I've noticed have happened so slowly that I almost didn't
realize it. While typing, I can see a broader swathe of the program on the
screen than I used to. Code smells popup in my head way sooner. While typing
logic patterns that are common, my brain seems to be able to think across the
entire program better rather than get caught up in the current file and
program flow. All this probably because the brain doesn't need to constantly
flit around telling me what key to press.

Because of all this, I tend to use keyboard shortcuts everywhere. Whenever I
start using a new program regularly, I either memorize or create keyboard
shortcuts.

Now, when people give me credit for being fast or more productive or knowing a
language better, I think probably all of those things, even if true, would
surely have taken longer if I didn't know typing.

I tell this to every beginning programmer. But sadly, till date, I've not seen
anyone dedicate the time to learn this one skill that would help them in their
careers, in their knowledge, in their life, in so many ways.

~~~
kilroy123
Do people honestly not know how to type by the time they become programmers?

I've used a computer since I was 5 years old. I can type without looking. (I'm
sloppy as hell though, since I was self-taught.)

But everyone I know types without looking.

~~~
tracker1
This is precisely why, to this day, I hate all laptop keyboards... the feel,
and spacing is just so different, it's hard to get used to. I'm typing this on
a Unicomp 103-key modem-m style keyboard... spacing is closer to original vs
104-key. Can't express how much better it feels.

At work, I'm using a mechanical keyboard with Cherry MX blue switches, to be
(slightly) less annoying, but it's still a very different feel to it. These
days, my only pain points are that getting natural scrolling outside of a mac
is difficult (windows wants to keep resetting it back) and ubuntu removed it
from the options, and it doesn't always work. And the ctrl/cmd characters on
mac feel wierd... I've got cmd in lower-left and cmd at alt position, but in a
console it's of course backwards in terms of muscle memory. And in mac
home/end don't work as expected.

Not sure where I carried off into a hardware rant... but all the same, what
you touch and look at are surprisingly important.

------
hermitdev
The ability to learn/adapt.

As a software engineer, you need to evolve to adjust to the ever changing
landscape that you work in. Whether it means learning the next evolution of
the language you know (e.g. going from C++98 to C++11, 14 or 17), picking up a
new library or even a new architecture (e.g. x86 to x64).

You must always be learning. Usually this means a lot of reading, some
experimenting. But, the uniform constant is: learning.

If you know how to learn (and how this is done differs a lot between
individuals), you have a shot at surviving as a software engineer. If you
think you now know all you need to know and all you ever will know...well, you
might as well inscribe your tombstone in the industry right now.

~~~
nnd
This is mostly true, unless you specialize in legacy technology to serve a
niche, like COBOL mainframes. In this regard the profession is similar to that
of a doctor or a lawyer, where the knowledge body is not as impermanent.

~~~
hermitdev
I think the learning mechanic still holds. You've still got to learn the old
paradigms, but if/when there's an impetus to migrate, you need to learn the
new paradigms and (hopefully) provide useful & cost-effective knowledge during
the migration (my last project as an intern at a Fortune 500 company was to
rewrite a legacy batch-processed mainframe Cobol application to a web-based
.Net application. I had to learn at least enough Cobol to understand what was
being done in order to replace it. Went from about a 45kloc Cobol program to
about a 10k .Net program w/ about 5k of xml configuration. Point is: even if
you're not going to write in a language, sometimes you need to understand a
different one. I think I saw perhaps the worst language I've ever seen: "MOVE
NEXT SENTANCE", which jumps, unconditionally to the next period in the source.
Yes, a statement "MOVE NEXT STATEMENT" jumps to the very next period, aka ".".
It's a very large goto statement that jumps to an extremely terse label. I
don't mind appropriate usage of gotos in C/C++/C#, but this construct is just
ripe for abuse and misunderstanding.

------
watwut
1.) Prioritization. Think straight in situation with a lot of work and decide
what is important first instead of jumping into panic mode.

2.) Everyone here focus on teamwork, but I would add a bit opposite one too:
ability to work independently for non trivial length of time.

Meaning: stays working and motivated without needing manager with all those
sticks and carrots. Able to keep module clean without _needing_ others to
review it. Able to make decisions - whether architectural or time vs feature
set ones or how to prioritize. We often socialize juniors to be completely
dependent on elders giving them pretty much zero autonomy. They are smart and
all that, but then fail the moment there is a lot work to do, detailed
supervision is not available and they suddenly needs to make own decisions.

3.) Willingness to listen to other peoples ideas and thinking about them.
Ability to distinguish between "bad code" and "different then what I would
do". Seriously.

~~~
tomyws
Good list. I'd expand your first point to include time estimation when
prioritising decisions! It'll come in handy, particularly when project
planning either short or mid-term.

------
rwmj
The ability to ignore the latest fad, but know the basics.

If it wasn't known about in 1980, and it wasn't published in a peer-reviewed
paper since then, then it's probably not worth worrying about.

~~~
PretzelFisch
This approach fails on the job resume. You'll never have 15 years experience
with yesterdays new fad if you ignore it.

~~~
eeZah7Ux
It will fail for those companies who hire a buzzword checklist. You don't want
to work for those companies.

------
sixdimensional
So my own anectdotal experience in this has shown the author's suggestions to
be true. There's only one major catch that you don't start realizing unless it
impacts you - your physical ability to actually absorb and retain continued
constant learning.

We have to work longer and harder (into advanced age) these days to survive.
While many people can learn and adapt and absorb for a long time, I don't
think it's true that everyone is that way. Some people, as they age, have more
trouble being able to constantly learn and instead end up "stuck" at a certain
level of knowledge/skill/ability. In the world of tech where you can get
flattened competitively speaking if you fall too far behind, it's incredibly
difficult and can become infeasible.

Especially difficult if you end up going down the path of memory related
diseases. For example, in my family we have dementia running in a few
generations. The onset of dementia often shows itself in small ways far
earlier than advanced age, for example, the inability to retain short term
memory can kick in much earlier.

This is one thing that drove my feeling that I had to be as successful as
possible and earn as much as I could when I was younger- not to be rich, but
in case I literally was unable to keep the pace in the future.

But on the bright side, I have aspired to keep my mind open and learning as
much as time permits, as the author discussed. So far, my colleagues have
always told me they thought I was always a font of knowledge and I always tell
them that it's only because I keep trying new things. Not because I actually
"know" everything I talk about, just because I try to dabble and learn
constantly.

I will say though, learning too much breadth, while really fun and a totally
valuable way of learning (you start to see cross disciplinary patterns and
connections between all kinds of things) - can lead you the "Jack of all
trades master of none" conundrum.

------
rethab
I think what specifically you need to know about largely depends on the field
you are working in.

A colleague once told me it is important that you are constantly working on
something in your free time that is _not_ something you do at work (eg.
different technologies, different programming languages paradigm, different
database type, etc).

This simple advice does two things: You are constantly learning, and you are
making sure you're looking beyond whatever it is you are doing for money. You
are widening your horizon. Maybe you discover something that you can
eventually use at work, maybe it will never be useful.. Who knows in which
direction we're heading?

~~~
lutefisk
Sounds like a recipe for burnout. I've tried a few times picking up a new
language in my free time, but since I program for work it made my days feel 3
hours longer.

I've started picking up hobbies unrelated to programming, it's much easier to
spend the time learning something completely different.

~~~
rethab
So when I said "work on something not work related", I didn't necessarily mean
"creating a side-business". It could also be studying or something. In my
specific case, I try to study a specific subject each week, for which I invest
4h per week. In fact, it doesn't even have to be technical, I just try to
focus on something rather than reading bits and pieces about everything on HN,
Twitter, etc.

------
biztos
"Paint every day" is great advice for staying sane and remembering the craft
of programming (or for that matter painting).

I don't know how old the author is, so I have no idea what "5-10 years" means
to him, but for anyone not at the beginning of their career I might add:

1) Add value well beyond any specific "engineering" you do. Beyond a certain
point you will be valued for what you bring to the business; your coding mojo
becomes less interesting to everyone as you get older.

2) Be good (get better) at the social part, including the boring meetings. Or
make your "F-you" money in the startup world and do whatever you want... but
if you don't do that, over time you will need to be good at the interpersonal
side of the business you're in.

3) Don't treat #1 or #2 as excuses to stop caring about the code. Even if you
make SVP and can't (shouldn't!) care about the company's code in detail, you
should still care about your own, and about good code in general. Otherwise
they will see your soul at the edges of your eyes, and it will be corrosive.

Like probably most of us, I need to work more on #2, and get better at
explaining #1.

I do code every day, meaning 5-6 days a week; but I admit that I struggle to
actually _paint_ regularly (I am also a painter). Working on it...

------
kozikow
I will go against a mainstream of answers like "soft skills" and "computer
science" as it's not news that those skills matter. In addition to timeless
skills you also need to bet on some new technologies.

I have bet on container orchestration and deep learning. Some people would say
they are at risk of becoming a fad, but both have been used in solving
previously seemingly impossible problems and are rapidly advancing.

~~~
biztos
I doubt deep learning is a fad, considering how "deep industry" (so to speak)
is now slowly getting interested.

And I think container orchestration will be a Thing for a long time to come,
because it's such a pain in the ass. This will be a source of friction for
years to come -- somebody set up the damn containers already -- so I think
your choices look safe.

OTOH they might be wildly different skills, for better or for worse. The Deep
Learning person is probably not going to be the Container Cluster Wrangler.

------
gizmodo59
The following are always good to have in my opinion:

Operating Systems

DBMS

DS and Algorithms

Proficiency in one of the languages(C/C++,Java,Python)

Very good communication skills

------
closeparen
As a counterpoint to learning something "new" every day, it might instead be
wise to learn something you already know, but _deeper_ , every day. As fields
advance, the trend is towards specialization.

If they aren't already, expert-level skills in a few areas should be worth
more than tutorial-level skills in a few dozen JavaScript frameworks.

~~~
newbear
So then, what should I be in expert in? Narrowed down to JavaScript.. And
assuming my real passions are outside of programming

------
throwaway12378
As somewhat of a failure on this front, I think social skills are very
underrated. You may be quite smart, but you know what ? Without a good network
you're doomed. We as an industry might like to pretend it is a meritocracy but
it hardly is (this from someone who spent a good deal of time in academia).

------
ChicagoDave
Primarily, maintain your ability to learn new things, whether it be languages,
tools, concepts, strategies, platforms. That's the abstract answer.

The concrete answer is the cloud. Learn what serverless microservices are, how
to build them, deploy them, and integrate them into a large system. Cloud
devops is already growing leaps and bounds and just like we needed to know our
OS in the past, we're going to need to know devops in whatever cloud we're
using (AWS, Azure, Google, ???).

Learn Lambda's and functional microservices. Learn Paas and Saas, learn how to
use a tool like DynamoDB even if it doesn't fit your prejudices for a data
store.

Learn unit testing. You should be able to unit test and integration test using
mocks in any platform you need to work in.

Agile project management. Sprint planning, planning poker, kanban boards,
choosing tasks vs. being given tasks, retrospectives...these are all important
to learn.

Keep some semblance of knowledge of metal. What I mean is, write some low-
level code to understand how memory works, how things work internally within a
platform. It's not important to be an expert, but understanding some of the
nuts and bolts of software engineering will make you a better programmer.

Listen to everyone without prejudice. I can't say this enough. Everyone has
ideas and even though new ideas may not make any sense to you, keep an open
mind.

Be inclusive. Always try to make people around you better at their jobs.

Manage your emotions. You can be passionate and sometimes even obstinate about
solutions, but manage how you interact with people. The greatest success comes
from moderate temperament.

------
k__
I started blogging this year about specific web-dev problems. One post a week.

Coding AND explainibg really helped me to question my knowledge .

[http://dev.to/kayis](http://dev.to/kayis)

~~~
klibertp
It's almost impossible for me, unfortunately.

When I set out to describe something, I quickly discover how little I know
about the thing. I then proceed to learn the missing bits. The time flows and
when I finally feel I know enough the original problems seems too trivial to
warrant a write-up... Or the post becomes many tens of thousands of words long
behemoths that no one wants to read :(

~~~
Brakenshire
I'd say most of the reading and writing of blog posts are in the "long tail"
of people attempting to solve a niche problem in a technology they don't know
intimately. Of course most of those are trivial if you already know enough to
solve it, but that doesn't mean they're not useful. Extra points for including
the conceptual explanation of why it is in fact trivial rather than just the
practicalities.

------
vitiral
Learn how to write (and edit) design documents. Realizing things are a bad
idea early is the best way to do it, and nothing pushes needed change more
effectively than a concise and well thought out design doc.

------
ronilan
Wordpress.

 _Wikipedia says: WordPress was used by more than 27.5% of the top 10 million
websites as of February 2017._

With so much agony to go around, ones ability to ease the pain will always be
in demand... :)

~~~
t0mk
Let's formulate a skill-in-demand forecast based on Wordpress ubiquity, but
sceptical.

I start:

\- Static CMS Advocate - someone who explains that setup for a landing page
with contact form doesn't need to consist of Nginx, Varnish, Apache, mariadb
and redis.

------
vosper
Lots of soft skills in this thread (which is not a bad thing; plenty of good
stuff there) so I'll give you a technical one:

I have been following Typescript and I increasingly believe that it will
displace traditional backend web development, and we'll end up with Typescript
on the backend and the front end. I think this because:

\- it's a very modern language with great type features (it's clearly better
than JS in my mind) \- it's got tooling support in all the major IDEs \- it's
under rapid development \- it's being pushed ahead by Microsoft, and other big
industry names \- it's been/being adopted by many projects, and it seems
especially by people in the React space. \- Node is mature for server-side

If I was a Rails developer in particular) or a Python person who only does web
(Python's not going away in scientific computing) I'd be keeping an eye on it.
The way Typescript is going it may end up being a better, safer, faster
language than Python [0], with the benefit of running in browser, on the
server, and as a mobile app via React Native.

[0] this might be part of why Python is slowly starting to move on the typing
front, but given there's still a lot of people on 2.x it'll be a while before
progress is made. And it's only type hints, not enforcement.

------
imafish
Can anyone with wife and kids attest to the feasibility of "painting every
day"?

~~~
wasted_intel
Wife and two kids, here. 30 minutes a day is what I strive for, with breaks on
weekends. Totally feasible.

~~~
jon-wood
You make a fair point. I posted the opposite while you were writing this, but
I could probably fit in 30 minutes a day. I'm just not sure how much I could
learn in that little time - it can take me that long just to get into the
right mindset.

~~~
dbancajas
I also had this problem of difficulty getting in the zone. I find that doing
it constantly as a habit you get in the zone easily. Plus the knowledge will
be stewed in your brain while you're at work. So you're not really only doing
the project when sitting in front of the keyboard.

------
PretzelFisch
Listening, oral and written communication, Leadership and mentoring.

------
yawz
Learning to learn better, and also learning to practice better.

------
kc10
Can't agree more. I also strongly believe movement is life. Movement
introduces you to new people, new skills, new technologies and new patterns.

My point is just don't get comfortable with what you are doing. The
"repeatable comfortable thing" you are doing today would become obsolete one
day.

------
BeetleB
I just gave a presentation at work about how we're ridiculously overeducated
on technical skills, and ridiculously undereducated on social dynamics.

I mean, I solved more complex technical problems in my undergrad than I've
ever had to in my career.

My suggestion: While you may want to master a technical skill or two, become
good at what they don't teach you:

Negotiation skills:

[https://www.amazon.com/Getting-Yes-Negotiating-Agreement-
Wit...](https://www.amazon.com/Getting-Yes-Negotiating-Agreement-
Without/dp/0143118757/ref=sr_1_1?ie=UTF8&qid=1488045020&sr=8-1&keywords=Getting+To+Yes)

[https://www.amazon.com/Bargaining-Advantage-Negotiation-
Stra...](https://www.amazon.com/Bargaining-Advantage-Negotiation-Strategies-
Reasonable/dp/0143036971/ref=sr_1_1?ie=UTF8&qid=1488045053&sr=8-1&keywords=bargaining+for+advantage)

The Coursera course from the University of Michigan is decent, if you don't
want to read. But the other course (from Yale?) - I would not recommend that
as a starter.

Communication Skills:

[https://www.amazon.com/Difficult-Conversations-Discuss-
What-...](https://www.amazon.com/Difficult-Conversations-Discuss-What-
Matters/dp/0143118447/ref=sr_1_1?ie=UTF8&qid=1488045088&sr=8-1&keywords=difficult+conversations)

[https://www.amazon.com/Crucial-Conversations-Talking-
Stakes-...](https://www.amazon.com/Crucial-Conversations-Talking-Stakes-
Second/dp/0071771328/ref=sr_1_3?ie=UTF8&qid=1488045088&sr=8-3&keywords=difficult+conversations)

[https://www.amazon.com/Nonviolent-Communication-Language-
Lif...](https://www.amazon.com/Nonviolent-Communication-Language-Life-
Changing-
Relationships/dp/189200528X/ref=sr_1_1?ie=UTF8&qid=1488045125&sr=8-1&keywords=nonviolent+communication+by+marshall+rosenberg)

Influence:

[https://www.amazon.com/Influence-Psychology-Persuasion-
Rober...](https://www.amazon.com/Influence-Psychology-Persuasion-Robert-
Cialdini/dp/006124189X/ref=sr_1_1?ie=UTF8&qid=1488045143&sr=8-1&keywords=influence)

(His work is often cited in other books - especially related to negotiations).

Networking:

[https://www.amazon.com/Never-Eat-Alone-Expanded-
Updated/dp/0...](https://www.amazon.com/Never-Eat-Alone-Expanded-
Updated/dp/0385346654/ref=sr_1_1?ie=UTF8&qid=1488045185&sr=8-1&keywords=never+eat+alone)

Finally, a word of advice. Most of us here on HN have no trouble reading stuff
and grasping its content. _Internalizing_ it, though, will take work. So don't
run away reading all these books. Pick one topic (e.g. negotiation), and read
up on it. Take notes (I forget 80% of what I've read after a few months). And
try to practice it.

Life is a marathon, not a sprint. Just focus on one till you feel you are good
at it (perhaps for a year). Then pick another topic.

~~~
scarface74
I haven't read this book but I listened to a podcast (Knowledge @ Wharton)
where the author was being interviewed. It seems like it might be worth a
read.

[https://www.amazon.com/gp/aw/d/1119081459/ref=ox_sc_act_imag...](https://www.amazon.com/gp/aw/d/1119081459/ref=ox_sc_act_image_4?smid=ATVPDKIKX0DER&psc=1)

------
throwaway_374
Frankly, interview technique and practice, specifically competitive
programming style questions. Entirely pointless and cargo cult but without
these skills come a rainy day you will struggle to land a job with the current
interview obsession trends.

------
ImTalking
I would say change one's attitude from a technical-person who happens to make
money programming, to a business-person who writes code. You must put business
first and understand that coding is only a tool to be used to further
yourself.

------
ruok0101
Lots of Q2 time. [https://czartodotcom.files.wordpress.com/2012/04/time-
quadra...](https://czartodotcom.files.wordpress.com/2012/04/time-
quadrants1.png)

------
nnd
I don't think it's fair to compare software engineering with painting. One is
(mostly) a craft, and another is (mostly) an art form. You success as a
software engineer is defined by how fast you can learn, be that a new
programming language or a javascript framework, although there are exceptions
of the rule if you specialize in some legacy technology which still needs to
be maintained. You success as an artist doesn't involve fast learning, but
rather creativity and marketing skills.

~~~
biztos
As a painter and a programmer I'm very wary of comparisons between the two,
but I think the article was getting at something different.

Namely: the daily practice of doing what you do.

This can be any discipline, and it can be multiple disciplines for the same
person.

It does look like there's a certain advantage to quickly learning the latest
thing, but that's a job-hopper's advantage. I don't think the fast learning of
fashionable things makes one a better or more respected engineer than the deep
learning of useful things. (I admit there may be more money for job hoppers,
in case that's the measure of success here.)

Success as an artist is a much more complex, chimeric thing than just
creativity + marketing. But it doesn't happen without a lot of discipline,
even if it's the same boring discipline one can achieve by going to the gym
three times a week.

If you study the great artists throughout history, even contemporary ones, you
see time after time the "1% inspiration, 99% perspiration" formula.

------
Clubber
I've been playing a lot of pool lately. A family member gifted us an Olhausen
8'. I played quite a bit in college. It's good, cheap entertainment. A little
bit of exercise, and a great way to take your mind off whatever.

If you are talking about technologies, WebAPI is what all the kids are using
these days, it's a more clever implementation than web services (WCF). Who
knows what current saplings will grow. I usually don't pick something up until
it's fairly well established.

------
faragon
Being aware about the Dunning–Kruger effect [1], focus in deliver instead of
blindly following brain-dead process religion/s (put your favorite
agile/religion here), and learn to identify the best possible talent so you
can work with good people ({smart + productive} coworkers makes you grow).

[1]
[https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect)

------
dandersh
The ability to learn coupled with the willingness to adapt.

More specifically you should look to balance out what you already know with
something new. If you spend your weekdays making CRUD apps, don't spend your
free time investigating (yet another) different way to make a CRUD app. Learn
machine learning, operating systems, etc.

For an actual field, I would think anything to do with large amounts of data,
whether it's machine learning, data visualization, etc.

------
moo
Finding another career path.

------
eranation
People skills and other soft skills, including time management, focusing,
simplifying, getting your message across, explaining complex things in an easy
way. Getting people motivated. Getting yourself motivated. Always learning and
never assuming you are in a spot that you can afford to stop learning and
being curious.

------
ballaa
Ability to work across disciplines especially in sectors where digital
transformation is having a large impact.

~~~
petra
How does one improve on that?

~~~
ballaa
Working on embedded systems is how I got started on that path

------
petra
Since stacks change and generally become more abstracted, i would say domain
skills: Good ability to work with domain experts and deeply understand the
domain and do it in a timely manner, write code as close to the domain level
as possible, and having domain knowledge.

------
rasjani
Many posts already mention these but in tl;dr: soft skills and ability and
will to learn new things.

------
lasereyes136
Communications skills or ability to learn. Technology will come and go. Best
practices evolve all of the time. What technical skills that are best today
aren't tomorrow. Learn to communicate and how to learn new things.

------
edem
Mark Cuban says: “Artificial Intelligence, deep learning, machine learning —
whatever you’re doing if you don’t understand it — learn it. Because otherwise
you’re going to be a dinosaur within 3 years.”

------
meddlepal
Communication, people management and organization.

Being able to work with your team effectively is IMO extremely important
especially for engineers that jump around a lot to different jobs, teams and
corporate cultures.

------
stevesun21
I would suggest that a mindset that can design systems to solve problems.

------
pryelluw
Learn how to sell/market yourself. Lesser engineers who can market/sell
themselves will have work when others wont. Its a cruel reality but thats
life.

------
Animats
Statistics and machine learning, or you're toast.

------
smonff
Having cultural background to deal with non technical stuff. Being able to
understand your manager, your boss, your customers, your colleagues.

------
nunez
Learning how to talk to people and sell things. Fads will come and go, but
sales will always be here to stay.

------
dlwdlw
Follow your heart, but realize when you're just making an excuse to be self
indulgent.

------
dboreham
Communication with other humans.

~~~
Razengan
I thought we develop technology so we don't have to do that.

------
donovanm
The fundamentals of computer science. Data structures, and algorithms in
particular.

------
__robin
Healthy work/life balance.

------
thecity2
Some knowledge of machine learning, especially deep learning.

------
drharby
after x-amount of years, it's not so much skill-sets that are valuable, but
personal qualities, imo.

------
happy-go-lucky
Math and physics.

------
Findeton
VR.

------
mcs_
YouTube

------
gaius
Morse code. Trinary logic. Radio propagation. How to construct an efficient
thermocouple from random junk.

~~~
dTal
Ouch. Found the doomsday prepper.

~~~
mindcrime
I think that list would be more like:

1\. How to start a fire with flint and steel, or other technique without
matches

2\. How to purify water by boiling, iodine, distilling, etc.

3\. How to build a shelter using a pocket-knife, some string, and an old tarp.

4\. How to trap, kill, skin, dress, and cook wild animals

5\. How to catch fish with a homemade hook, or with a spear

5.5 How to make a spear

6\. etc.

And actually, when you think about it, all of those are things that very well
could be valuable.

~~~
biztos
_off-topic and half-joking but..._

1\. How to predict whether your neighbor will help you or try to kill you.

2\. What to say to the Authorities when they find your prepper camp.

3\. How to raise chickens in secret.

4\. How to fully comply with all orders until you can make it to the border.

------
Entangled
Swift. For the next 5-10 years.

SQL. For the next 100.

Logic. Forever.

------
daysforbeef
Application of Category theory and abstract algebra to Software engineering.
Application of Category Theory and abstract algebra to API design and library
design. Category theory -> composability on steroids.

P.S whoever thinks otherwise is an idiot and what's wrong with the software
development world

~~~
2_listerine_pls
e.g.

~~~
daysforbeef
Example -> use of Monoids in the design and implementation in the Diagram
Library from composition of primitives to caching

