
Ask HN: What topics/subjects are worth learning for a new software engineer? - jmeiha
I&#x27;m trying to cultivate my ability to identify worthwhile topics to invest time in learning since I have only recently graduated from university, so for the most part have been sticking to the yellow brick road laid out for me thus far.<p>What would some of you guys think about learning if you were just starting out in the industry? Or even better, what does your process for orienting yourself and making these kind of decisions look like?<p>Any and all advice would be greatly appreciated.
======
baron816
Too many software engineers get into a mindset of “just make it work.” For me,
making it work is only half the battle. You need to build something that will
make it possible for you or someone else to come back to later and be able to
reason about and modify or extend.

I interview a lot of job candidates and I give them a very simple problem.
Pretty much everyone can solve it, but I’m not just looking for them to solve
it. I’m looking for them to find the right abstraction—one that will make it
easy to extend the problem and for junior devs to look at the solution
function and understand exactly what it’s doing. Almost no one passes.

My coworkers ask “just make it work” problems in interviews, and I believe
that has contributed to our codebase being a nightmare to work with.

I think most software engineering is an organization problem, rather than a
optimization problem. My advice: learn functional programming and object
oriented design. You will learn how to write declarative code that is loosely
coupled and not dependent on its context.

~~~
dudul
> I’m looking for them to find the right abstraction

Nothing worse than an interviewer asking a design/coding question and who
already "knows" which answer he/she wants.

~~~
adjkant
This 100%. There's a big difference between looking for maintainable and
extendable code and the "right" solution. To me, that almost no one passes is
a red flag - if you are screening resumes right and framing the question
right, the pass rate should be at least 25% IMO.

Extensibility/maintainability also exist on a spectrum - a less than ideal
answer can still be pretty close.

~~~
baron816
I’m fine with less than idea answers. The problem is that most people I see
prematurely optimize and don’t try to abstract the problem out at all. Or they
only abstract one small part, or a part that makes no sense to abstract. They
gravite to one big function that does everything. Our codebase has a lot of
big functions that do everything. The only time people try to break things up
is to make it DRY. Any time we need to change things, it breaks something else
entirely unrelated.

~~~
fao_
> _The problem is that most people I see prematurely optimize and don’t try to
> abstract the problem out at all._

Have you ever heard of Premature Abstraction[0][0a]?

> _Our codebase has a lot of big functions that do everything. The only time
> people try to break things up is to make it DRY._

That's the whole point of DRY, though[1]. If you abstract with less than three
instances of it, you will end up with abstractions that typically misfit the
solution, requiring refactoring or outright disposal of the abstraction in the
future (Or worse). Also, you waste time developing (what in all likelyhood are
bad or leaky) abstractions when you could be devoting time to something more
important.

> _Any time we need to change things, it breaks something else entirely
> unrelated._

That's unrelated to abstraction.

There, I said it.

Leaky or badly fitting interfaces are not solved by abstracting more, they're
solved by compartmentalizing more (There's a subtle difference here). This
_can_ be done with abstraction, but doesn't need to be. Typically refactoring
the data structures, shuffling state around, or redesigning the interfaces to
better fit the problem, is a better solution.

[0]:
[http://wiki.c2.com/?PrematureAbstraction](http://wiki.c2.com/?PrematureAbstraction)

[0a]:
[http://wiki.c2.com/?TooMuchAbstraction](http://wiki.c2.com/?TooMuchAbstraction)

[1]:
[http://wiki.c2.com/?ThreeStrikesAndYouRefactor](http://wiki.c2.com/?ThreeStrikesAndYouRefactor)

------
yashap
Take on challenging problems, ask lots of questions. Always try to understand
both the technical decisions and business decisions/value in whatever project
you’re a part of.

Try to avoid anything resembling blog/resume driven development - the real
things to worry about are writing code that solves the business problem in a
simple, quick way, while being easy to modify in the future, low on bugs, easy
to monitor, and ideally reasonably performant. Using hot new frameworks/tech
is unimportant, but writing well tested, modular code with the right data
models, simple architecture, and good logging/telemetry/alerts is very
important.

Get comfortable with a set of tools that make sense for the work you’re doing
- an editor/IDE, a debugger, a shell (and common Unix programs, if you’re in a
Unix environment), a VCS, whatever build/deploy tooling your company uses,
etc.

Avoid the common dev mindset that dev managers, product managers and/or
designers are the enemy. It IS your role to focus on important technical
needs, but realize that they must be balanced against delivery times and
business value. Sometimes you need to leave hacks in place, if there’s not too
much cost to leaving them there. New features and bug fixes ARE often more
important than cleaning up code/architecture, when you do take time for
technical priorities, make sure you’re choosing high impact ones.

~~~
Aeolun
I think you are needlessly dismissing resume driven development.

While I agree that it is no good from a technical perspective, it’s really a
fairly big part of what companies look at when they hire you (as I learned).

Make sure it contains at least the latest fancy technologies in a professional
context, and it will really help with your desirability.

Then after you join the company, you can try improving their code to be up to
standards.

~~~
yashap
We might have a different definition of resume driven development. Choosing a
company that uses a tech stack you think will be good for your career is fine,
though it wouldn’t personally be one of my top criteria. But what I’m advising
against is choosing frameworks, architectures, databases, etc. for a specific
project, simply because they’re the hot new thing, vs. actually being the best
choice for the problem you’re trying to solve, at the company where you’re
solving it.

Also, I personally don’t think the specific stacks you’ve had experience with
play much of a role in getting top dev jobs. Getting great referals from
senior people is generally the best way to get top dev jobs IMO, and you get
these referrals by shipping reliable, high quality software consistently, and
being pragmatic/mature.

~~~
Aeolun
Explain to me how I’m going to get referrals from the people I’m working for?
If I ship reliable, high quality software, they have every incentive to keep
me.

I mean, old coworkers could potentially be a source of referrals, but not
really.

~~~
yashap
I’ve found most high end hires work this way:

\- Person A and person B work together, both are fairly senior

\- Person B moves on to a new company. New company is hiring for a
senior/lead/staff/director/whatever role. Person B says “we should recruit
person A, I’ve worked with them before and they’re great”

\- Person A gets recruited for a great position, gets it as long as they do
well in the interview

On the flip side, I haven’t seen “experience with specific hot new tech” play
much of a role in hiring for senior positions. I’ve conducted around 150 dev
interviews, plenty of them for senior+ positions, and we’ve always taken the
opinion “let’s just hire a smart, experienced, mature person, who knows what
it takes to ship software, and knows how to balance technical priorities with
business priorities. Ideally with a glowing referral from someone we trust.”
We always assume that someone like this can learn our tech stack fairly
quickly. Like at my current workplace we use a lot of Scala, MySQL, Redis,
Kafka, K8s and gRPC, but would happily hire someone senior who’s used none of
those technologies, but who has used similar enough ones, say Java, any
relational db, any key value store, any queue/pub-sub system, VMs and REST.

------
auslegung
I was recently given this list of books by some very skilled engineers who I
trust

1\. [The Pragmatic Programmer]([https://pragprog.com](https://pragprog.com))
2\. Martin Fowler's [Refactoring
Book]([https://martinfowler.com/books/refactoring.html](https://martinfowler.com/books/refactoring.html))
3\. Kent Beck's [Test Driven Development: By
Example]([https://www.amazon.com/Test-Driven-Development-Kent-
Beck/dp/...](https://www.amazon.com/Test-Driven-Development-Kent-
Beck/dp/0321146530)) 4\. [Thinking in Systems: A
Primer]([https://www.amazon.com/Thinking-Systems-Donella-H-
Meadows/dp...](https://www.amazon.com/Thinking-Systems-Donella-H-
Meadows/dp/1603580557)) 5\. [Zen Mind, Beginner's Mind: Informal Talks on Zen
Meditation and Practice]([https://www.amazon.com/Zen-Mind-Beginners-Informal-
Meditatio...](https://www.amazon.com/Zen-Mind-Beginners-Informal-
Meditation/dp/1590308492)) 6\. [Pragmatic Thinking and Learning: Refactor Your
Wetware]([https://www.amazon.com/Pragmatic-Thinking-Learning-
Refactor....](https://www.amazon.com/Pragmatic-Thinking-Learning-
Refactor.../dp/1934356050))

------
icc97
My personal opinion but this is purely because I enjoy it the most is
functional programming. So much of the positive changes I've seen of late come
through functional programming.

For example:

* ReasonML - this is what the founder of React is working on now. The ReasonML claims itself to be JavaScript 2030 (I see it as JavaScript + TypeScript + Immutable.JS + Redux). This contains a lot of the concepts from JavaScript so is a reasonable step to make

* If ReasonML isn't too scary it leads you down a path to OCaml, F# and Elm

* Rust (not strictly a functional programming language, but is ridiculously fast and contains well implemented Linear Types that makes Haskell's Simon Peyton-Jones jealous [0]) - this is one of the most loved programming languages according to the Stack Overflow survey

[0]:
[https://www.youtube.com/watch?v=t0mhvd3-60Y](https://www.youtube.com/watch?v=t0mhvd3-60Y)

------
analog31
Don't get too busy. This is easier said than done.

I've noticed that when we hire newly graduated engineers, we saturate them
with CAD (or its equivalent in programming), bureaucracy, and troubleshooting.
They forget the cool stuff that they learned in college, such as math and
theory, and burn out.

If you want to keep up with that stuff, you have to figure out how to weave it
into your regular work, so you have an excuse to continue learning more about
it, or give yourself some free time to learn cool things that you might use
later, or might not.

A lot of people tend to measure _themselves_ by how busy they are. I believe
that's a death trap.

------
OliverJones
I've been at this for a long time. I've had to learn many new languages,
toolchains, and stacks over the years. I try to read at least one technical
book a month. So will you. That's a fact.

Understanding systems (no, not operating systems, not file systems, not that
stuff) will give you the ability to create really good stuff. By "systems" I
mean, basically, human systems. For example, understanding why the New York
City subways are working poorly these days involves knowing something about
politics, economics, electronics (the signaling systems) and demographics.

Knowing why software companies sometimes have a hard time "putting themselves
out of business" involves technical debt, new technology, resistance from
people who know how to succed and want to keep doing it.

Why doesn't the Roman Catholic Church let their clergy marry? That's the
mother of all systems questions.

How to bust into this way of thinking? Read "The Fifth Discipline" by Peter
Senge. Be an anthropologist. To practice, read worseThanFailure.com as am
amateur anthropologist. Don't just laugh, try to figure out WHY people do
silly-seeming things.

~~~
__exit__
When you mention technical books, do you have in mind books on programming
languages/frameworks or more focused on general concepts/skills useful for the
daily work?

~~~
OliverJones
Both kinds of books. I subscribe to O'Reilly's Safari Books Online, and read
whatever looks interesting.

------
corysama
Ask old engineers about their problems and they’ll tell you it isn’t tech.
It’s all people. Getting people to understand, get motivated, relax, get over
themselves. These are the issues that hold back progress in practice.

But, if you want tech, machine learning really is horribly interesting and
useful right now. Ocaml and Erlang are good systems to learn from and carry
over to other systems. CUDA is a rare and powerful skill. And, if you want to
get serious, learn TLA+ or Coq.

------
pulkitsh1234
On a related note (sorry for hijacking)

Should you invest time in learning for interviews or your own personal growth
once you are 2-3 years in the industry ?

I understand that both sets are not mutually exclusive, but where should you
put your time on ?

Investing time specifically to give interviews: Leetcode, Cracking the Coding
Interview, TopCoder, etc., may increase the chances of getting a better job
then your current one (and will make you a better programmer too).

On the other hand reading books like 'the pragmatic programmer' and other
classics, won't necessarily put you in a better position to get a better job
(in most companies), but will surely make you perform better in the current
one.

So, is it ok to put it this way:

* If you are happy with your job and you can see that you can stay 5+ years at the company (basically FAANG ?): Invest time in learning for personal growth (Design Patterns, Refactoring, etc)

* If you plan to switch / want a better salary / company sucks / <every_other_reason> : Invest time towards preparing for interviews specifically ?

~~~
avocadoLife
This is exactly my dilemma. I've been in the industry for 2 years but done
very little personal development in my own time and my job has been quite
limiting in pushing my skills in the direction that I desire.

I value my after work hours to pursue other things/exercise/have a life. This
makes me put even more thinking into how should I be spending my already
limited time.

Currently I'm sticking to doing some MOOCs related to my my development path
(Android) and then I want to crack on a few personal projects. On the other
hand, the clock is ticking and I really would love to prepare well for better
career opportunities...

------
skrebbel
Learn to ship.

Make something useful, even if just for you and maybe three friends. Ship
that. Sooner. Ship it when it hardly works. Then iterate.

This will teach you all the good bits of "agile", some requirements thinking,
pragmatic programming, and (if it's a web thing) some basic "how to maintain
an app on a server" skills, all in 1 go. It's also all stuff that is super
hard to learn from books or from too-experienced coworkers.

~~~
garysieling
I found that blogging the steps as I do side projects made progress really
helped with this - it makes it feel like I'm always completing something. It
also allowed me to break a problem down into small steps (what be done in 30
minutes-1 hour before work).

------
3pt14159
Understand that questions that anyone reading HN can answer are largely filled
with answers and votes that are what the average HN commenter thinks. The
average HN commenter makes an average wage.

Find people that sold businesses or make high six digit incomes and ask them.

That said, my two cents[0] is that you should run towards the hard stuff, not
away from it. Seems hard? Seems ill-defined? Top dollar.

AI, Rust over C, Ember over JQuery, complex ETL jobs, OS programming, ASICs,
FPGAs, space circuits, military gear, OS simulators, codebase analysis tools
for red team, nano second computing for wall st, etc.

My only proviso is that you should probably stay away from learning about
cryptographic algorithms unless you're also interested in learning about
quantum computing. Crypto right now is pretty easy and cheap for the 99.999%
of entities that need it; and unless you're _really_ good you're probably not
going to break modern algos without quantum and even if you do there are a
very small number of actors that will pay for your genius. MITM attacks that
involve breaking crytpo algos are mostly state actors and huge criminal gangs.

[0] I guess I've sold a company, but some people working at Google have made
more than I did so I don't really feel like I fit the category of people you
should be asking.

~~~
01100011
> military gear

Maybe. I think there are lucrative opportunities in serving the military
industrial complex but they are best exploited by insiders with experience and
connections in that space. You need to know the lingo and need to know the
right people. You also, probably, need clearance, which you can usually only
get by being former military or formerly in the defense industry.

~~~
3pt14159
I'm open to hearing perspectives if you have personal experience or friends
with experience here, but that has not been what I've found to be true.

My int / mil friends got in quite easily once they possessed the skills. They
were all white, non-muslim, non-Russian and born in Canada or the US, but
other than that even people with dual citizenships got S or TS clearance and
worked on some crazy ass shit.

~~~
01100011
Did they get their TS clearance without being sponsored by a company who was
already doing business with the government? It's my understanding that you
need to get your start working for an existing government contractor and then
you can branch out on your own. I don't know of anyone who went straight from,
say, college into getting TS and starting a military contracting company. Also
there are a ton of rules when dealing with the military that often require
experience with those sorts of arrangements. Even my company, with extensive
experience in that area, received a substantial fine because we bid on work
which we no longer qualified for.

~~~
3pt14159
Oh, this is where we have different experience. I went to Waterloo, which is
generally where a ton of our top CS and Engineering grads come from. Many
(both Canadian and American citizens) went straight into spookware or military
gear with no prior connections.

------
vogre
Learn SQL and you will be able to work with any data-related app. Learn HTML
and you will be able to make an UI out of nowhere. Learn GIT and you will be
able to share your work with others. Learn unix shell so you can deploy all
that shit and conquer the world.

~~~
chubot
Yes it feels like SQL, HTML, and shell are ubiquitous and powerful
technologies that most people think they know, but probably don't. Certainly I
could have learned more about them in the first decade of my career. 15 years
into it, this knowledge continue to pay dividends.

I like this contrarian advice: rather than chasing the latest new thing, learn
SQL, HTML, and shell. They continue to exist because they do things well that
Java, Python, and Go don't. I suspect that will still be true in 10 years, so
it's a good thing for new engineers to invest in.

(Learning the foundations of git is good too, although the outer layers are
arbitrary and nonsensical.)

------
snarfy
In most other professions from doctors to electricians, years of experience
equates to years of expertise. In software development, the technologies
change so rapidly that a large amount of time is spent learning the
technologies and tools. You may be a veteran Java or C++ developer with
intricate knowledge of the underlying frameworks and implementations. At some
point those technologies are replaced and that knowledge is worthless. All
those years of experience are gone. Sure some general experience was gained,
but anything related to specific implementation details is gone.

The only thing that stays are the fundamentals. Focus on the core science and
math aspects of software development, and your skills will only grow over the
years, instead of constantly being deprecated as the landscape changes. Learn
all of the design patterns and O notations and forget about the latest
javascript framework flavor of the week.

~~~
mayankkaizen
What a valuable comment!

I am 37 and I am not a programmer but I do read a lot about programming and
related areas. Practically speaking, I don't see myself becoming a
professional programmer but I still want to pursue programming just to whet my
learning appetite.

But what puts me off is this 'framework' dependent programming. It is just
frustrating. Your knowledge of framework just doesn't stay with me. And I
really don't learn anything fundamental.

------
leetrout
I invest in my tools and learn a bit more than what I need to make them
functional. This isn't always a tech deep dive- sometimes it's just being a
"power user" and knowing the shortcuts.

I haven't met a recent grad in the workforce that uses git to its potential.
They cargo cult workflows which is a good start but get in to trouble by not
understanding just a bit more about how you can make temp branches / rags to
keep from destroying commits in a rebase or how to prune duplicate commits
from a sloppy rebase.

For terminals - using tmux or screen and understanding how they work enough to
pair up on a remote box.

For any language knowing how to debug and how to profile. Understanding that
print/println/log debugging is great and just keeping moving when figuring out
why something isn't quite right.

This isn't a hard answer to what you asked but it's what popped up in my mind.

~~~
majewsky
> I invest in my tools and learn a bit more than what I need to make them
> functional. This isn't always a tech deep dive- sometimes it's just being a
> "power user" and knowing the shortcuts.

If you (the asker) are using a Unix environment, I would recommend that you
set up a weekly appointment, maybe every Friday, where you sit down and read a
random manpage. Not for the sake of memorizing everything, but to learn what
your tools can already do if you just remember to look up the right invocation
when you need it.

~~~
hyperpape
I like the idea, but I don't think a random man page is the best approach. The
signal to noise ratio is quite low. Maybe look at something like Julia Evans'
bite sized linux.

~~~
marmot777
Why does it have to be random at all? Why not start at the beginning of a
Linux book and something like [http://wiki.bash-hackers.org](http://wiki.bash-
hackers.org)?

Even acting systematically leaves room for astonishing synchronicities.

------
davidwihl
Learn about data, data science, statistics with a guise towards Machine
Learning. Learning about data and statistics will give you a skill in numeracy
that will be very distinguishing compared to the majority of developers (as
evidenced by the other comments). This will help you quantify your
accomplishments, ask thoughtful questions about the numbers others (including
product managers) use to make decisions and give a fresh perspective to
arguments that often lack credible facts.

Taking this further, with more math, can lead to proficiency in Machine
Learning, which I think is the most important change in computer science in
the last ten years, and likely very important to all developers in the next
ten.

Background: started three companies (IPO, sale to a big tech company,
crash'n'burn), CS degree from an Ivy, now working at Google.

------
captn3m0
1\. Learn to Ship

2\. Read everything on this list: [https://blog.codinghorror.com/recommended-
reading-for-develo...](https://blog.codinghorror.com/recommended-reading-for-
developers/)

3\. Learn to go down the stack. The best engineers I've worked with know their
stack deep.

I wrote a blog post on this once (targeted at recent graduates, should be
helpful): [https://captnemo.in/blog/2015/10/12/get-better-at-
software-d...](https://captnemo.in/blog/2015/10/12/get-better-at-software-
development/). The list on the blog post is:

1\. Join a community.

2\. Contribute to Open Source projects

3\. Write all code publicly

4\. Do tech talks

5\. Stay Updated

6\. Learn more languages

7\. Concepts Matter

8\. Ship Products

9\. Have side projects

10\. Read technical books

~~~
__exit__
Knowing a stack deep is rather difficult when one attempts to also learn and
keep up-to-date with the newest technologies. Or were you referring more to
system/protocol stacks instead of programming languages/frameworks?

~~~
captn3m0
system/protocol stacks. Your ability to debug things faster and more
accurately improves drastically if you can guess/know what is happen on the
abstraction layers below you.

------
agitator
If you are working at a new job, ask questions, ask lots of questions. The
more you put your ego aside, and focus on absorbing everything like a sponge,
you will leap ahead of your peers and your early career will set you up for
long term success.

Often times, imposter syndrome will keep people from asking questions out of
fear of being judged as incompetent. Let me tell you, the people who
immediately ask about what they don't know are the ones you want around, the
ones who pretend to know, or struggle through issues, or end up with odd
solutions that need to be reworked take up more time and cost teams more
money. The more you seek to understand form other more seasoned engineers,
your peers, etc will only benefit you and will also have the added effect of
building relationships and respect from others that will also set you up for a
better long term career.

------
PopeDotNinja
Learn to pay attention to that feeling that tells you an abstraction is
missing. When you try to bring something to life using the tools you know & it
starts to feel much harder than it should be, that's a good sign there might
be another tool out there you can use to get the job done. If you can't find
anything, that's a good time to start asking if it makes sense to try a
different approach or build your own.

------
codingdave
Like many questions, it would be easier to answer if we knew what your goals
were. Do you want to grow into being the lead software person in a small
company? Found your own place? Be a contributor in a large space? Work in
academia? Teach? Be a digital nomad? Do design-driven web work? There are
hundreds of choices of where you can end up. And they all result in different
answers. So if you'll pardon a cliched question -- where do you want to be in
5 years? What would that person know? The answer to that question is what you
should be studying.

~~~
jmeiha
Interesting - you've pretty much hit the crux of my issue. I'm pretty aimless
right now, which is a big part of why I struggle to make choices on things
like this. Setting definite goals is something I've always kinda danced
around, it would be good to build up a habit of doing so going forward.

Thanks for the words of advice, definitely has me thinking.

~~~
theresarapior
Your journey will evolve over time, too.

But to get started, just get stuck in building some web app that helps you or
is funny to you, and throw it on heroku as a project. Put everything on github
and begin growing your coding resume that way.

A software engineer friend was telling me last night why it's so hard and
exhausting to learn. It's because you use so much thinking power learning
something new, but the more you do it, the more it's muscle memory, like
driving a car. Maybe 80% of the time you spend learning will actually be
tiring and boring and hard. So, it's probably going to be painful at first,
but having the drive to complete projects and get stuck in will get you where
you want to be (even if you can't decide where that is, yet :) )

One warning would be to stay away from just learning languages. Logic and
syntax are important for sure but knowing all the tools needed to build one
piece of software is where you gain useful skills.

------
VargasTheOld
The basics, the stuff that is one or two levels of abstraction below the
'normal' stuff. Write a compiler, write a query optimizer for an open source
SQL database, write a new IO subsystem or memory allocation subsystem for
MINIX, write a kernel for a Vector PU in, say, CUDA. Write a 4k demo in
assembly. Grab a soldering iron and built your own mouse then write a driver
for it. Write your own TCP/IP stack.

When I was a student, way too many years ago, the Uni I attended was very
heavy on theory, lots of discrete math, physics, calculus, Big O analysis,
electronics and computers architecture, Lisp, Prolog, CLISP, data structures
and algorithms, wide search vs deep search, rebalancing red black trees on
paper, etc. At the time I was very unhappy about it, I thought "why are they
not teaching us C++, Visual Basic and this new language called Java that it's
clearly the future?" But now, twenty years later I am very happy with the
formal education I got. Having an understanding and an intuition of how things
work all the way up and down the stack from transistors all the way up has
proven invaluable during my professional career.

------
vinayms
The most important thing to remember is that technology of all kinds, software
frameworks and even programming languages themselves come and go, mostly
affected by the whims and fancies of the megacorps that own them, or the
communities that eventually implode into a thousand forks, whereas abstract
design and techniques, aka algorithms and analysis, are forever (well, as long
as we stick to the Turing machine model). It might seem boring and
disenchanting for a recent graduate to know that the "dry and boring" stuff he
just got done with will be recurring forever, but that's the way it is (if you
are creative then nothing is dry and boring anyway). Even things like design
patterns and best practices are basically product of the technologies and the
general state of affairs that people had to wrestle with at different times,
so they have a shelf life and must be reevaluated before application, without
succumbing to cargo cult or taunts and ridicule. These things are after all
opinions of few influential people propagated by their minions (jk), and not
laws of nature as observed and analyzed for centuries by great minds. Its
alright to have counter opinion as long as its not contrarian just for the
sake of it.

The second thing to keep in mind is that computer science/software engineering
is basically like metallurgy - its purpose is to produce tools to make lives
better, mostly for STEM people but also for laymen. So, while its perfectly
alright to have some fun building sand castles in the foundry, it must be
remembered that there is a greater purpose. An offshoot of this point is to
pursue your interests in non "tech" field of your choice by getting away from
computers every now and then; you never know from where you would get your
ideas and where your ideas might have an application. As software guys we have
an inherent freedom, much like artists, to explore other fields of knowledge,
for it has benefits of many kinds. So avail it.

------
Peteris
I'm going to take a very different stance here from others.

First, you should ask yourself - what kind of engineer do you want to be. Why
are you building?

Then, read about the people who became the best and their early days. What did
they do when they were in your position? Did they study a set of topics or did
they pursue their passions? Taking and highly-weighing advice from people not
at the top of the field could be very detrimental to your development as an
engineer.

From reading books like: Coders at work, Masters of Doom, Making of Karateka,
you will realize that the best engineers were driven by their ideas and
projects very early on. They ended up learning to make things happen. But
don't take my word for it, find these people, study their stories and pick the
path you would enjoy the most.

This approach will not just make you a strong career engineer, but could turn
you into one of the greats - the people that get to push the field forward.

------
_hardwaregeek
Design. Tech can bloom and fade. Languages can be hyped and forgotten. But
design stays. Learn to empathize with your users. Learn to design stuff that
works well but also allows for fixing when it breaks. A good developer
understands the interfaces and communication that is inherent within writing
code.

------
akudha
One non-tech answer is learning to listen and learning to ask intelligent
questions. Assuming you are writing software for people to use, these skills
can be very valuable talking to users, executives and pretty much anyone a
software engineer deals with. Maybe this is not too useful if you are working
on some non user facing stuff like hard algorithms or protocols, I don't know.

I've seen even experienced people end up asking _leading_ questions and get
the answers that they want (or think are right), instead of just letting the
other person tell them what their thoughts. The result is weeks or months of
wasted effort, bugs and user unhappiness.

------
perlgeek
There are lots of topics you could look into:

* testing

* logging

* writing code that is easy to operate

* deploying code

* build systems

* algorithms

* API design

* refactoring

* security practices

* development processes (scrum/kanban/whatever)

* learning about the vertical / business domain you're in

To be honest, I didn't plan too much ahead -- there were some topics that
simply interested me (algorithms, security), and others I was thrown into
because work made it necessary (build systems / deploying, logging).

If you don't actively try to get into a niche, you'll get exposed to many of
these topics, and likely many more that I forget.

If you ever look back, and don't think you haven't learned anything new in the
last 3 or 6 months or so, then you should actively look for opportunities to
learn.

~~~
scarface74
_logging_

And for the love of all that is holy don’t just log to a text file. Use some
type of structured logging framework (Serilog,StructLog,etc.) that gives you
JSON structured logging that you can then query instead of depending on
regular expressions.

~~~
majewsky
Why though? Even if your own app logs JSON, everything around it (the DB, the
log collector, the metrics collector, the kernel, the LDAP server) most likely
logs plain text, so you need to know regexes anyway.

~~~
scarface74
Oh that’s the other part. With the structured logging framework that I’m most
familiar with - Serilog - if you send it to an output source like Mongo or
ElasticSearch it logs documents. So you can query your logs. With Serilog you
can tell it to always add certain attributes and you can tell it to add
attributes with a certain context - like everything in a “using” block.

As far as the logs that you don’t control, if they are in some sort of
standardized format even if it is just a line of text, you can use logstash to
create a structure around it.

Of course with ElasticSearch, you have a powerful reporting app in Kibana. If
you are on AWS you can send logs to CloudWatch and use the alerting, metric
framework that’s built in.

------
BurningFrog
The important skills in real life programming are about code maintenance.

\- Finding and fixing other people's bugs. Many people hate this, but you can
learn _huge_ amounts from this! After you've found the bug, understand _why_
it happened, and learn from it.

\- Writing code that not only works - that's the minimal, given level - but is
also maintainable and easy to change. By _other_ people, even. Who you've
never met, ideally.

\- Refactoring and testing are _essential_. If you're not spending at least
30% of you're time doing this, you're building trash.

------
traviscj
For the love of god, learn how database indices work -- basically everything
at [https://use-the-index-luke.com/](https://use-the-index-luke.com/)

------
Insanity
A few things that come to mind:

1) version control (git at least)

2) soft skills (how to deal with people)

3) learn some new languages outside of your comfort zone. Learning new
languages is always useful and you can get a feel of different domains

4) The tools you use to make your magic happen. Learn your IDE shortcuts,
optimize your toolchain.

5) And, kind of related, think about your ergonomics. Working at a computer
for 8 hours a day can be quite bad for your health. Make sure your environment
is good for you, desk at the right height, good mouse / keyboard, and maybe do
some sports on the side.

~~~
stevewilhelm
I would add learn how to do Test-driven Development

------
stallmanifold
Remember that software engineers have two skill sets: programming/development
skills and domain knowledge. Many of the comments here are focusing on the
former, but consider the latter as well. What kinds of problems do you like
solving? What (business) domain(s) do you find interesting? Start thinking
about that over the next few years and acquire knowledge of the business
domain(s) as well as leveling up your technical chops.

------
jtolmar
Completing projects does a lot to help you learn, and you can complete more
small projects per amount of time than larger ones. So give your learning
projects small, defined scopes.

Actually properly learn the tools you find yourself using a lot. Like if you
use javascript, don't be the guy who doesn't understand how "var" and "this"
behave. And don't feel pressured to know everything - if you only use Python
to edit scripts twice a year then it's fine to be looking stuff up every line.

Try to ignore programming fads, though of course as a person embedded in
society it's hard to know what's just hype. On average these things last as
long as they've already existed, so learning things that have been around
continuously for a long time is pretty safe. Since you're just starting, it's
particularly important for you to learn things that'll last a long time, since
you have longer to use them.

Learn something that lets you make a website backed by an SQL database. It's a
pretty safe bet you'll want to do things that fit this description a whole
bunch of times. This is also a place where a bizarrely small amount of
expertise can change "start asking for VC money" projects into weekend
projects.

You can go your whole career without ever needing to write a parser, unless
you know how to write parsers, then you'll see cases where they're the best
solution all the time. I don't actually know how much this is "if all you have
a hammer everything looks like a nail" and how much is "boy I'm glad I know
hammers exist."

It's more niche, but I've never regretted learning more vector math.

------
mattlondon
I'd recommend to learn several languages that are pretty different from each
other. E.g. java, golang and javascript. Learn enough to be proficient in each
- enough so you are fully comfortable in the ecosystem and could happily start
a new project from scratch and do it all in that language + ecosystem without
much help or stumbling blocks.

Benefits: learning multiple languages makes you better in each by opening your
mind to new approaches or reinforcing higer-level understanding... Plus you
won't become wedded to a specific language or "scared" of touching something
new you've not done before. You'll see more similarities than differences, and
although you may never actually get to code in java/golang/javascript
professionally the experience of learning and coding in the different
languages is really powerful in my experience.

Other than that, I am personally a fan of "full stack" development. Learn a
little bit about everything so you can hit the ground running on whatever
project you land on - web development, databases, mobile device, backend
developer, continuous integration, containers, serverles etc etc. Play around
with all of these and you'll learn _a lot_ about designing systems and what
really matters. Again - you'll see many similarities across all of these
apparently different areas of expertise, all of which will be to your benefit.

With respect, ignore comments about learning the tools - tools change rapidly
and you might not get to use your particular favourite tool/ide/editor/source
control system/operating system/hardware on your next proejct, so just make
sure you stay flexible.

Good luck - you're in for a really fun ride.

------
_Marak_
Learn about the concepts of Continuous Integration and Continuous Deployment.

Learn about implementing code coverage into your projects so you can track the
percentage of code paths which are actually being covered by the tests.

Once you have the mindset of actually testing your software and tracking the
code coverage your entire approach to development will change and improve.

------
rsyring
My advice to aspiring developers can be found here:

[https://www.level12.io/blog/advice-to-aspiring-
developers/](https://www.level12.io/blog/advice-to-aspiring-developers/)

I believe it will probably give you some of what you are looking for as well
as links out to other helpful resources.

------
honkycat
"Only a fool thinks himself to be wise."

Learn time management. People management. Fitness. Productivity science. Read
how the other people succeed.

A lot of very smart people take time to write excellent books on all of these
topics. Why make the same mistakes they did? Learn to read books, and learn
from the best. Adapt their lifestyles into your own.

------
GlennS
You've got a lot of answers here, and quite a few of them overlap what I'd
suggest. You're not going to be able to pursue them all.

Personally, I tend to learn things that are relevant to my job as I'm doing
it.

Aside from technical things, that also means learning the domain you are
working in if it's sufficiently interesting. For example, I worked in
healthcare for a while, so I learned to read the HL7 protocol and the most
important parts of the NHS data dictionary. Then I worked for an environmental
charity, so I learned about thermodynamics and government policy making.

If you learn the domain, then you will make more good decisions when you
design your program. You will also be in a better position to be trusted to
make those decisions yourself.

For technical stuff, I like to spend more time and go deeper on things that I
think are fundamental, things that I think will be useful in the future, and
things that I have fun with.

I don't like to spend time on things that I find yucky, that I intend to avoid
using again, or that I think are based on unsound fundamentals.

Sometimes I make wrong decisions in either direction. Either spending too much
time learning something esoteric irrelevant in the long term, or spinning my
wheels because I've skimmed over something without understanding it properly.
I don't know a way to avoid this.

A few specific things I think are good quick wins for a starting software
engineer:

    
    
      * Version control.
      * Known what a dictionary/hashmap is for and how to use it.
      * Set logic (intersection, union, difference, xor), and how to do it in your favourite programming language.
      * Automation (bash or Powershell + make + SSH). 
      * SQL + indexes (common in lots of computer programs, and SQLite fits nicely into the automation chain above).
      * Regex, how to use it in your text editor / IDE of choice, and how to use it on the command line. https://www.regular-expressions.info/

~~~
GlennS
Oh, also, I forgot.

Learn Excel properly:
[https://www.youtube.com/watch?v=0nbkaYsR94c](https://www.youtube.com/watch?v=0nbkaYsR94c)

When you're properly automating things you'll want to use programs and command
line tools instead, but you should still know Excel for the one-off quick and
dirty data inspection.

Also some of your colleagues will use it a lot, and won't have learned it
properly. You can make yourself very useful.

------
scarface74
I know this is going against the grain for HN, but I’m going to suggest not
learning the latest leetcode, computer science algorithms. Most places in
corporate America are doing cookie cutter problems that have been solved
before in different domains. Unless your company is operating at FAANG or even
Twitter scale, all of the cross cutting, infrastructure concerns have been
solved and you can use an existing piece of software to solve it and it’s
usually open source.

What I do suggest you learn that most people don’t know is going deeper down
the stack, domain driven design, continuous integration/continuous deployment,
at least one public cloud environment (Azure/AWS/GCP).

------
amriksohata
Hammer the people who should be coming up with requirements, the BA or PO or
whoever it is to take responsibility for proper requirements. From your end
read things like the Clean Code book and Head first design patterns.

------
jrvarela56
Product Development/Management. Understanding the ‘inputs’ to your role will
make you more effective. Learning the WHY you’re building helps you prioritize
and gives you credibility when arguing for/against decisions at a team level.

Learning about what a PM does has helped me make sense of how my work as a
SEng relates to management, product and design. Specifically, the way I now
spec, test and design systems in order to facilitate legibility, QA and
coherence with the domain of the product has been greatly influenced by my
amateur knowledge of product dev/mgmt.

------
danielrhodes
Learn a language exceptionally well.

One thing that makes younger engineers stand out is having mastery over a
language. This will be evident to most interviewers and will be a big help in
day-to-day tasks. It also opens the door to having a good mental model for
becoming very proficient in other languages, which you will definitely need to
be down the line.

Getting good at various patterns that are native to the language,
understanding how to profile/use debuggers, understanding memory and CPU
performance, the ecosystem, memorizing the standard library, etc are all part
of this learning.

------
GijsjanB
You need to narrow it down a bit.

Know yourself. Find your passion. I know this sounds tacky, but there are sooo
many variables in choosing a professional direction. You are the only
constant. For example, it is very important to determine what kind of
developer you are: quick n dirty, loads of languages, throw out some PoCs and
go on or... keep building till it's perfect, 100% coverage, solid docs, etc.
Than, what will you build? Embedded, games, web, medical, imaging, AI,
infosec, etc? Answer both questions and your next step will be easier to
define.

------
tmaly
I would focus on communication skills. Knowing what the end user wants is
really important.

For technical skills, I recommend reading Clean Code, Test Driven Development,
and The Philosophy of Software Design.

~~~
garysieling
Two thing sthat really helped me with communication skills were technical
blogging, and volunteering with Big Brothers, Big Sisters - trying to see the
world through the eyes of a teenager is really illuminating.

------
te_chris
Learning to understand the domain you're modelling thoroughly. To ask enough
questions so you don't build the wrong thing for the person who's requesting
the work.

------
Annatar
Operating system packaging: RPM, pkgsrc, ... You'll always come back to it as
being your primary building and delivery block and it will provide huge
benefits in terms of simplicity. You'll be running circles around everyone
else in terms of delivery, simplicity and robustness. The learning curve is
steep but well worth it, and it never stops paying dividends.

------
antoniuschan99
As long as you're working on projects you will gain knowledge in process and
skill. Examples of these are Agile, Cloud, Dev Ops, Programming,
Collaboration, etc.

You also may want to specialize both in your skillset (Front End Back End) and
Industry. Try to optimize by focusing on something you enjoy and are also good
at.

------
marichards
When all you need to do breach someone's privacy and often the law is publish:

    
    
      <a href="https://www.facebook.com">Facebook</a> 
    

then you need to learn about security and privacy and how to defend your users
against the failings endemic in the web.

------
neves
Very nice, but I still have to see a guide that doesn't just refurbish the
ideas from the late Jerry Weinberg great book:
[https://leanpub.com/becomingatechnicalleader](https://leanpub.com/becomingatechnicalleader)

------
pankajdoharey
My favourite is Go-Jek reading list [https://blog.gojekengineering.com/the-go-
jek-reading-list-10...](https://blog.gojekengineering.com/the-go-jek-reading-
list-1088712ccc14)

------
mr_toad
Which industry? There’s a lot of differences between, for example, embedded
systems and database administration. Or HPC and mobile app development. Or
even .NET and open source.

------
theresarapior
In short, choose a problem you have, then fix it the easiest way possible by
building software/website/webapp/whatever. Language doesn't even matter.

------
hirundo
Regular expressions: [https://www.xkcd.com/208/](https://www.xkcd.com/208/)

Also, study your debugger until you grok every feature and command, and then
keep studying it until it's firmly embedded in your muscle memory.

------
jeena
Learning how to deal with dependencies. Learning integration into a system.
Learning basic DevOps. Learning versioning of your software.

------
whalesalad
Things I look for when hiring: an understanding and appreciation for SOLID
principles. Major bonus points for hexagonal architecture.

------
di4na
System Thinking and look at what Human Factors and Cognitive Systems
Engineering does.

It is always applicable and it will be useful in any role.

------
xer
Read hacker news once every day and you will after a few years of reading be
above the average software engineer.

------
Graham24
Make sure you know about Orders of Complexity. Read the Mythical Man Month and
other old books on theory.

------
master_yoda_1
Office politics :)

------
michaelchisari
Stress management and communication skills.

------
carapace
Learn Prolog.

------
bra-ket
business

------
spiritcat
all of teh subjects

