Ask HN: What is your best advice for a junior software developer? - nothing_to_see
======
C4stor
Read the error messages. Reread them. Extract every piece of information from
them. Never close an error popup without having read and understood what it
means. Always read stack traces when you're blessed enough to have them.

100% of the juniors (and an awful lot of seniors) I've ever trained simply
ignore those and then come ask for help debugging.

99% of the time, the explanation for their problem is literally the first line
of the stack trace/error message/whatever is red on their screen.

If you successfully adopt the mindset of "whatever the computer is telling is
true from the computer point of view, so I'd better make sure I've read it"
instead of "Anyway, I'll try something else and run again", you'll debug 10
times faster. And since debugging is a good part of the job, you'll be a lot
more productive.

~~~
andy_wrote
I really like your last point "whatever the computer is telling is true from
the computer point of view".

In a surprising number of coding interviews that I've conducted, I've seen a
candidate write an incorrect solution that generates an exception and then
attempt to figure out the error almost on first principles, rather than
actually reading the exception carefully and thinking about what coding errors
could have caused it to happen. The exception message is a _huge_ hint!

It's a red flag to see someone try to debug without paying attention to it.
Conversely it's very positive to see someone encounter one and then think
carefully about it. Writing an incorrect solution but then testing it out and
showing the ability to debug and fix it systematically and expediently is no
worse than getting it right on the first try, in my book.

~~~
fhood
It isn't just a huge hint, most of the time it tells you exactly what the damn
issue is. This discussion is blowing my mind.

I am honestly speechless. IT GIVES YOU THE LINE NUMBER AND THE FUNCTION CALL
AND THE REASON! Why would you ever even attempt to debug without parsing it?

~~~
eitland
Wait wait wait.

Not so fast.

i'm one of those programmers who read manuals and stack traces but I have to
admit that I've seen my share of both manuals as well as stack traces that
didn't make much sense.

~~~
kickopotomus
This is my experience with Clojure stack traces ~60-75% of the time. Perhaps
it is a symptom of functional programming? A lot of function passing and
anonymous functions make it difficult to generate a meaningful stack trace.

~~~
lmkg
Clojure's stack traces are an issue with Clojure specifically, and how it's
hosted on top of the JVM. A lot of the stack trace you get is actually
implementation details of the Java objects making up the Clojure runtime. In
effect, the program that you get stack traces of is the Clojure interpreter
rather than your Clojure program which is running inside that interpreter.

~~~
vram22
Why do they do this, though? Shouldn't they have realized from the start that
such messages are not helpful, and should have given messages related to your
Clojure program? (Or is there some difficult technical issue related to
achieving this?)

Asking because reading about this issue in the past is one thing that has kept
me from trying out Clojure.

------
fb03
__do not burnout __

I know you are young and you feel like you 're invincible. I know you can pull
an all-nighter and work the next day just fine. We have all been in that
situation and believe me, it is gonna take a toll at your performance ... and
it could even trigger or help you develop some health issues in your life that
can sabotage you down the line.

Realize there's only so much progress one can do in the day. Stop before you
are absolutely exhausted and passing out, I know it's sounds tempting but
please please do not fall into the trap management or more senior people (that
were forced to do this too but didn't learn or are "paying it back" now
negatively) to wrest that one last drop of energy. After your X allotted time,
even if you are still feeling energized, go spend that energy jogging or
something! Work a craft, learn to play an instrument.

Risking to toot my own horn, this might be the single best non-technical
advice in this thread.

~~~
arandr0x
Aren't young people allowed to, well, be young though? When you don't go to
nightclubs, don't have friends to call at 1am and can't play guitar in your
400sqft apartment with neighbors on all sides of the world's thinnest walls,
is it a terrible thing if coding all day and all night on relatively minor
problems to make somebody else five figures a week is your primary source of
excitement? Does it not beat alcohol and Counter-Strike in the realms of bad
things for your health that generate dopamine?

(Totally agree with the advice who have money and relationships though. But
none of us start there.)

~~~
CogitoCogito
You should try to do whatever makes you happy. If it makes you happy to give
your labor away for free to some large profitable company, then by all means
do so. I would personally try to use my time for myself (either to make more
money or to do things I enjoy), but it's a personal choice after all. Only you
can make that choice.

That said, having balance is usually a good idea. If you have interests
indepedent of your work, you will be able to lean on those interests when work
isn't going well. This may not seem important now, but some day you may find
yourself tired and lonely working late at night without seeing the fruits of
those labors and suddenly your stuck with nothing else going on in your life.

~~~
arandr0x
I know that (I learned it at 25 though) but I don't regret being 19 and
unbalanced. I had fun in the end. Suffering is a universal human experience
and not something to be avoided at all costs or anything.

I mean, sometimes we give young people advice and they are super eager to do
everything right and use all the lessons the older people learned. I figure,
there may be value in learning that particular lesson on one's own and on
one's own time.

The recent Tesla news are a good warning bell against never learning it,
though. As was in a different way the recession.

~~~
CogitoCogito
> I figure, there may be value in learning that particular lesson on one's own
> and on one's own time.

I smart man learns from his mistakes. A wise man learns from the mistakes of
others. I mean sure I also went through similar unbalanced years as you and I
learned from them, but if I could go back and change something I would instill
some more wisdom in myself earlier. I don't live regretting that time of my
life, but if I had the chance I'd certainly do it differently.

------
qznc
Learn about the business side of the company. It helps tremendously if you
understand how management/sales/marketing/etc think.

Don't follow your passion. Passion will come if your work is meaningful, you
are competent and respected for it. So instead work on your competency in
whatever field. Leave if the environment will never respect you anyways.

All software problems can be solved if you work on it long enough. Do not give
up just because StackOverflow does not have the answer.

A really good question to ask for a task is "How do you know you are done?" It
might prompt to clarify requirements. It might prompt you to make things more
measurable or testable. It makes you think about implicit things like
following code guidelines. It makes you better at estimating time.

Never assume anybody is stupid. Instead, figure out how these intelligent,
well-intentioned and experienced people have come to a decision which is
stupid now.

Do not just fix symptoms but (at least try to) fix the root problem.

Participate in discussions instead of just listening. If you are wrong, then
you learned something at least.

Sit together with experienced developers. Watch how they use their tools.

~~~
sam0x17
> Never assume anybody is stupid. Instead, figure out how these intelligent,
> well-intentioned and experienced people have come to a decision which is
> stupid now.

On that note, don't assume that any particular existing piece of code you find
is somehow "blessed". Do assume that everyone, yourself included is a total
idiot and capable of writing fallible code, and in every avenue and every
respect of life, assume that there _may_ be obvious, ingenious,
simple/scalable/efficient/elegant solutions that have been overlooked leaving
open possibility of a better way. Never be annoying about it though.

~~~
ryandrake
I had the opposite problem when I was junior: I believed most existing code
was crap because “it’s not how I would have done it” and had trouble resisting
the urge to rewrite everything. Learning to live with and thrive with legacy
code is a great skill.

~~~
sam0x17
I was that way as well, but all the juniors I encounter now are the other way
around.

------
XorNot
On the slightly more negative side: everything management tells you that's not
in an email will have "never happened" when it's convenient.

When you have a conversation with anyone where you think a plan was verbally
agreed on, before doing anything your first action is to go back to your desk,
write it in an email, send it to them as confirmation and find at least 1
other person, ideally in your reporting line, which you can cc it too.

Because it doesn't take an actively malicious manager to screw you over - it
takes literally anyone who suddenly needs to change history to their own
seniors for it to fall on you, the underling.

EDIT: And the friendlier or more casual someone is, the more important this
becomes.

~~~
Bahamut
I have never had to do this nor seen anything like this behavior in my 6 years
of work in the industry. This sounds incredibly in bad faith, and I would
probably take it as a signal to go job search for a better work environment if
I witnessed this in my day to day.

~~~
PhasmaFelis
I think that's naive. The parent comment phrases it a bit more cynically than
I would have, but it's in everyone's best interests to casually document plans
and intentions. People forget, people misremember, people promise things
without fully thinking through the implications in the moment. A friendly
email restating the key points of a discussion is conscientious, professional,
and keeps everyone on the same page.

I'd personally be very suspicious of anyone who tells you _not_ to do that.
There is literally no downside unless you're trying to hide something.

~~~
Bahamut
My response to that would be that if someone remembers differently, they
should treat their coworkers with respect and give them the benefit of the
doubt if there is no reason why anyone should be skeptical. That is not a good
work dynamic if your coworkers are not doing that, and is cause enough for me
to start job searching.

If there is reason to believe that there are disagreements in actions to be
taken, then messaging everyone to get on the same page is ok. If someone is
actively throwing someone under the bus unceremoniously & quickly, then one
should prepare an exit strategy & a strategy for working around the
problematic coworker as a cautionary step because the spinner could
potentially stop at oneself. If it is more than one problematic coworker, then
the exit strategy approach becomes increasingly pertinent.

I think it is self-defeating to do other than this approach in general, and
far from naive.

~~~
restingrobot
I don't want to assume anything about your work history, but I have worked at
2 fortune 500 companies, and I can absolutely say that if its not in writing
it didn't happen.

Perhaps these companies were outliers, and I don't think anything I experience
was a result of malice. However, when the higher ups are looking for answers,
middle management tends to put blame on the developers. I can't tell you how
many times I had to dig up old email chains to essentially prove what was
communicated. People forget, people misremember, and people will fabricate to
avoid repercussions. I have found this to be a universal truth of business, so
I can see why someone would say your comment is naive.

Also like the comment above yours states, there is literally no downside to
re-affirming the discussed points. I've had instances where once things were
put in writing, my manager noticed something that wasn't clear and we were
able to circumvent issues.

------
spamizbad
Treat people with respect.

Sleep well.

Take care of your body and your mental health.

Try to turn any feelings of inadequacy or imposter syndrome into energy to
push yourself forward and increase your skills and knowledge. We've all been
there... multiple times.

Learn to code fearlessly: Are you being asked to run queries on a production
box? Ask if you can get a user with read-only permissions. Change crusty old
code? Maybe put a quick test harness around it.

If you're stuck when debugging a problem, think about all the assumptions
you're making, and then test each one of them, no matter how obvious.

Understand that code is often ugly and weird for a reason other than
incompetence. Code quality tends to be a function of time, requirements,
experience, and skill.

~~~
jrowley
This my favorite comment on this thread. Coding fearlessly is such a
privilege/skill - makes a world of difference.

~~~
sgt101
It's hard won.

When I manage to get a team to create a code base with good tests it turns out
that it's easy to change and resilient in the face of sudden requests for
features.

A poor test infrastructure doesn't do this, building a good infrastructure is
a skilled task. But worth it!

------
onion2k
Don't stress about not being good enough when you see other people's work.
People show off their end result and not the hundreds of broken iterations it
took to get there. You can build exactly the same stuff with a bit of effort,
learning and time.

~~~
jpfed
Corollary: if someone posts "my first X" to a big public site like reddit or
HN, it is almost certainly not literally their first X; it's just the first
one they felt comfortable enough to exhibit publicly.

(At least, that's what I tell myself...)

------
rkangel
Read at least HackerNews and possibly some other tech news site regularly. And
then make sure to not get too caught up in the hype for new stuff.

As someone working in technology, you are going to be learning new stuff
continually (or your usefulness is going to diminish over time). By keeping up
to date with tech news, you get a lot of context for what people are using,
what's coming down the pipe etc. You may end up experimenting with stuff and
then you'll be ahead of all your colleagues. It broadens your knowledge, and
if you have to deal with clients it means you will usually know what they're
talking about.

There's a few pitfalls to watch out for though. HN is great, but it is still
an echochamber that can be focused on web and related tech. I was mostly an
embedded software engineer for years and found comments like 'does anyone even
use C anymore' hilarious (yes, see Linux kernel, device drivers, and your
washing machine for details). It can also be very easy to end up wanting to
push for the 'shiny new thing' too early. I tinkered with Rust from very early
on, but it's only in the last 6 months or so that I'd suggest it is ready for
use in most companies (depending on application area). Javascript frameworks
suffer this problem particularly badly. Mature beats shiny 9 times out of 10 -
running into a problem that 100 people have met before and posted about on
StackOverflow and your tool caters for, is much better than being the first
person to encounter said problem.

~~~
Boulth
> Read at least HackerNews and possibly some other tech news site regularly.
> And then make sure to not get too caught up in the hype for new stuff.

Interesting because I advise the exact opposite: do not waste time reading HN,
just find one thing that is interesting and master it. Then repeat.

As much as I like HN there is a lot of noise here. Novice mind can easily fall
into a trap looking for signal here.

~~~
sevensor
I've gotten a lot of value from reading HN. I've also wasted a lot of time. It
helps to develop a personal filter. Mine is

* Avoid headlines that make me angry, unless the news is really important. The discussion is never worthwhile, don't even bother.

* WSJ, Bloomberg, and WaPo won't let me read articles with w3m, so I skip the article. If the topic is tremendously interesting, I'll check the comments.

* TED and nautil.us are the information verison of empty calories. I've never gained any long term benefit from reading them.

* Javascript framework churn is intense. It's not worth trying to keep up with the details unless you do web development. If, like me, you don't, it's still worth reading the headlines to keep abreast of what frameworks are popular, what paradigms they embody, and who's pushing them. This changes every six months or so.

* It's always worth scanning the comments in threads about programming languages. There are some _really_ interesting people who sometimes jump into those threads and blow your mind.

* Know your prejudices and look for information that challenges them. My prejudices are that I think Windows is lame, that MacOS is infuriating, that Javascript is terrible, that vim is better than emacs, and emacs is better than IDEs, and object orientation is a failed paradigm. So I look out for articles that have a different point of view. I've learned that Microsoft has some really interesting technology, that Apple is infuriating even to its own users but it doesn't matter because they're sitting on the world's biggest pile of dollar bills, that Javascript is usually unnecessary but occasionally useful, that kakoune is even better than vim, and that nobody agrees about what object orientation even is.

~~~
Eire_Banshee
"object orientation is a failed paradigm"

uh... wtf?

~~~
Reedx
Here's an explanation from Casey Muratori:
[https://youtu.be/GKYCA3UsmrU?t=4m50s](https://youtu.be/GKYCA3UsmrU?t=4m50s)

See also Mike Acton (Engine Director @ Insomniac Games):
[https://www.youtube.com/watch?v=rX0ItVEVjHc](https://www.youtube.com/watch?v=rX0ItVEVjHc)

~~~
Zimahl
You aren't going to get a lot of support for OO in places where it isn't
really necessary like games, and especially games with single developers. At
that point the management of data is on the developer. Essentially one is
saying that if they fuck up the data, that's on them.

OO is handy in enterprise software where there are lots of developers who may
not understand why things are the way they are, they just need to do
something. In big, complex systems where a lot of things are going on, if you
give someone a noose, they will hang themselves. OO can protect data from some
(of course not all) unintended consequences.

------
baccredited
Save 25X your annual spending and you can retire. If you invest to earn 7%/yr
(on avg), you can withdraw 4% forever.

Read the book The Simple Path to Wealth, or the basics in this blog post.

[http://www.mrmoneymustache.com/2012/01/13/the-shockingly-
sim...](http://www.mrmoneymustache.com/2012/01/13/the-shockingly-simple-math-
behind-early-retirement/)

~~~
kjullien
Could anyone explain this a little for me, please?

Does this mean you save 93% of your income and only use 7%?

From the website, there is a graph that shows how many years you supposedly
have to save for retirement but it does not take into account the actual
amount you make.

As a "junior" dev, if you save 97% of X peanuts you still have peanuts.

~~~
hellogoodbyeeee
The 7% is referring to the rate of return on your investments. He is making
the assumption that if you invest $100 in the stock market on January 1, then
on Dec 31 your account will have $107 in it. This assumption is an average
over many years.

There is a common rule of thumb in the investing world that you can safely
remove 4% a year from your investments and they will continue to grow. (7%
return minus 4% withdrawals means you have 3% more in the account each year)

It doesn't matter what your lifestyle is. If you are a junior developer who
makes 80k a year and spends 50k a year, then you should save 25x50k=1.25mil
and then you no longer have to work for a living. This process will take years
or decades.

~~~
Z-Widwil
Quick question. Is the 80k an example you threw out, or a reasonable amount
for a junior dev to make? Specifically for a a mid-sized company in the
States, outside of Silicon Valley.

Currently working as a junior dev and the senior devs feel I'm making less
than I should be. Which is much less than that 80k. The only caveat being that
my employer is also paying for part of my tuition (up to a max of $5000 a
year). Previously, this seemed like a decent increase with what I was making,
but adding that 5k to my wage and I'm still nowhere near the 80k.

I'm throwing out this comment as it seems like it would be beneficial to other
junior devs to have a ballpark amount to shoot for. Obviously other factors
play into this (e.g. healthcare, location, etc). This just seems like a decent
play to ask without breaking taboo with local devs.

~~~
ptmcc
It's obviously location dependent, but in most any booming US city (Seattle,
Denver, Austin, etc.) a junior dev should be making at least 80k unless they
are truly green.

------
dub
I advise junior developers that there are primarily two difference between a
junior and senior developer:

1) A senior developer is unafraid of not knowing things. When we join a new
team or company, we're as lost as any junior developer joining them team. We
ask as many questions as necessary to get our work done effectively, without
shame or fear of looking foolish for not knowing things already. We are good
at searching through unfamiliar codebases to figure out how they work.

2) A senior developer (or any productive person) is good at saying no. People
will ask for more of your time than you can spare. You can gently but firmly
say no, direct people elsewhere (delegate), or ask people to discuss with your
manager whether more of your time can be allocated to help them.

~~~
donatj
I would argue willingness to say no is what separates junior from senior.

In my experience it actually leads to Juniors being abused a lot of times
being given dumb projects someone should have said no to. Then code review
rolls around and the seniors are like “what is this” and there’s a dumb fight.
Lol. Maybe that’s just the places I’ve worked.

~~~
jcalabro
I don't think you're the only one who has experienced this; we hired a couple
of new grad programmers recently and they've really been put through the
ringer. Not necessarily on dumb projects, but projects that one might
categorize as urgent but not important.

------
TheAceOfHearts
Try to sleep 8 to 9 hours every day. In this JRE podcast [0], Matthew Walker,
a sleep expert, claimed that sleeping poorly can decrease your performance by
30%.

Strive to maintain a good work-life balance. Burnout sucks. Your health and
family are more important than work. A workplace that doesn't consider this to
be the case is likely to be toxic.

As for actual software development advice... Beware blanket statements. They
can help you develop a low-resolution model so you don't suffer from
paralysis, but real-world problems tend to be complex and messy.

Here's an example: if you were building a traditional web app, many software
engineers would probably suggest using something like PostgreSQL. That doesn't
mean other database technologies don't have their place. However, PostgreSQL
is able to adequately serve a large category of problems with relative ease,
so it often makes for a sensible starting point. Once you become more
familiarized with that domain you'll develop a higher-resolution model and you
can begin to evaluate other technologies more effectively. Much of software
engineering is about figuring out what tradeoffs to make.

Another example in traditional web apps is using cookies for auth. Using
cookies for this purpose is well documented and pretty much supported
everywhere. There's plenty of known problems with using cookies for this
purpose, but the alternatives also have their own set of issues to deal with.

My final example: testing. Testing your code is great and it can be very
useful, especially when refactoring or developing new features. But going for
100% code coverage is usually more trouble than it's worth. It's also very
easy to end up writing a bunch of useless tests. You want to focus on the
actual problem and not waste anyone's time.

[0]
[https://www.youtube.com/watch?v=pwaWilO_Pig](https://www.youtube.com/watch?v=pwaWilO_Pig)

~~~
Flow
> Strive to maintain a good work-life balance. Burnout sucks. Your health and
> family are more important than work. A workplace that doesn't consider this
> to be the case is likely to be toxic.

Good advice.

It's likely burnout will really change you for the rest of your life if you
don't react early enough.

It's a bit sad when you realize you'll never again be that guy you grew up and
identifies as. But you also have to realize that was a person with habits that
wasn't sustainable and now you have to live with that.

------
Flow
Realize almost everyone suffers from Impostor Syndrome from time to time.

Read a lot of code, not just code in the projects you work on, but
reference/framework source code, open source. Perhaps even ask a subreddit for
the language/tool about good examples to learn from.

Realize that data is more important that code for the most part. So treat data
like it's precious. That's one part of why I feel relation databases are
better than document/object stores. I suppose this is up for debate.

Learn to say No. It's mutual respect to say No so the one asking has a chance
to ask someone else. If you instead say Yes to too much and can't deliver too
close to their deadline you might screw up other people's time plans.

Outside work: Avoid eating junk food more than 1-2 times per week. Keep your
weight. Go to the gym or run. Take the bike or walk to work. Sleep at least 6+
hours a day. Limit work to 40 hours/week. It's better to do 40 fresh hours
than 50+ zombie hours.

~~~
mvcatsifma
"Realize that data is more important that code for the most part. So treat
data like it's precious." This is excellent advice.

------
brogrammernot
Ignore the bullshit.

Languages are tools, and you are a craftsman (or woman). In the same vein, a
carpenter doesn’t scoff at using a wide variety of tools and of course has
favorites but doesn’t get caught up in them.

Frameworks will come and go, understand how they work under the hood.
Understand how Node works, aka V8 engine + C++. Understand why React is so
popular but also understand it’ll pass in time as well.

Most of all, just find what you enjoy in programming. If you don’t like
architecture that’s totally cool. If you love writing middle tier software,
that’s cool. If you like being full stack, totally fine. There’s plenty of
jobs in each area so spend time finding what you like.

~~~
vorpalhex
And understanding how different technologies work will help you build
expertise in future ones more easily. Technologies are not usually born out of
thin air, they inherit approaches from earlier ones.

------
vishnugupta
I admit this is more of a laundry list than a single advice — as you are
looking for the _most_ important advice — I’ll nevertheless list them down.
Roughly ordered by importance :-)

* You are expected to manage your career and growth. Don’t rely on or expect your manager or someone else to do that for you. You’ll get lots of good advises around how to grow in your career. It essentially boils down to taking initiative and driving those to closure.

* Understand the product _end-to-end_ as an end-user. All the use cases, all the flows.

* Understand the business model, how it relates to the product and how that product (or part of it) in turn relates to what your team and you are working on. This is much harder than it sounds which is why you need to relentlessly pursue this. The code base you are working on has an abundant of domain knowledge and architectural decisions built into it. Build a mental model of both that domain knowledge as well that architecture. You will rarely find those documented so you need to put in a lot of effort to know all the use cases and relate them to control and data flows. Trace different requests through the system, use whatever tools that are at your disposal (debugger, logs, metrics etc.,). This mental model will really help you accurately estimate feature requests.

* Help those around you in whatever way you can. Treat all the functions (HR, finance, marketing etc.,) with equal respect. Get to know them, what they do on a daily basis, their pain points. If not to help them then at least to empathize with them.

* Actively look out for inefficiencies (e.g., build taking 20+ minutes, broken unit tests, chronic production issues) and take time out to fix them. Even if no-one appreciates this you will have at least a feeling of fulfillment of having achieved something valuable to the business/company. In the process, you will have learned something new.

* Make _full_ use of vacation policy. No one’s going to tell you to take a vacation you gotta take care of your physical/mental health yourself.

~~~
azrael49
> You are expected to manage your career and growth. Don’t rely on or expect
> your manager or someone else to do that for you. You’ll get lots of good
> advises around how to grow in your career. It essentially boils down to
> taking initiative and driving those to closure.

This is huge. For any junior devs, please take the time to learn about how to
plan and enact career progression and technical growth. I learned the hard way
that if you don't do this for yourself, nobody will.

------
mping
Always work with people smarter than you. Ethics are important. Don't stop
trying to improve. There is money to be made in every IT area, follow what you
like and you wont be poor or unhappy. Respect others' work no matter how
crappy, specially open source/free work.

~~~
btschaegg
While those are all good points, I feel like

> Don't stop trying to improve.

can't ever be overstated.

------
bpyne
Soft skills matter!

Learn how to write good emails. Write to the point of view of the
person/people receiving the message. If you can't describe a requirement
without technical jargon, you probably don't understand the requirement.

Learn how to phrase questions and responses in a thoughtful manner. Knee jerk
responses are usually detrimental.

Learn how to present. You're going to have to make a case for your ideas in
meetings. You'll also have to defend your actions sometimes, particularly with
respect to operations and support.

Communication is so critical. It helps requirements become better understood.
It keeps issues from becoming escalated so that you have more time to do the
enjoyable part of the job: creating something for someone.

Your job is to make someone else's life better with your development skills.
Whether it's saving a step in a task they need to do or providing timely
information so they can make decisions important to the
organization...whatever...you're there for them.

Explore what areas of development you like the most - analysis, project
management, UI, backend, etc. - and follow them. Keep in mind that it may
change in the course of your career.

Try to develop a good rapport with your colleagues. You spend a large portion
of your waking hours with them. It's easier when you like them and vice versa.

Find enjoyment in each job. It's a long career. Don't stay with something that
isn't enjoyable to you.

------
jason_slack
Take your job seriously.

I often have felt that Jr. Devs I have mentored only live up to the "Jr. Dev"
role. They only do as much as they think a Jr. Dev should do and often leave
work for a more Sr. Dev instead of at least trying to take a stab at
something.

Example: a JR. Dev has trouble implementing some candlestick graphs. Instead
of trying to work through the issues and document his thoughts in the code and
ask for advice. He just leaves it untouched, for many days, then a week,
before someone asks him his progress then says "while I can't quite make it
happen" when really nothing has happened.

~~~
suhas2go
This is something I'm personally following right now - so it struck a cord
with me. I see other Jr. Devs simply stick to their roles, I cannot do this -
I try to understand a feature/project and work according to its requirements
and not just do my work

~~~
jason_slack
I would hope that no Sr. Dev ever scolds or looks down on another dev for
trying, regardless of skill level. I'd rather someone try than twiddle their
thumbs. Good luck.

------
tomohawk
Develop good habits: physical conditioning, mental conditioning, avoiding
drugs and alcohol, etc. If you want to be doing this kind of work for the long
haul, protect your body and mind. In your 20s, you can be a couch potato, etc,
and probably do this job. In your 50s? The proportion of people still doing
this job who don't take care of themselves is much smaller.

~~~
azrael49
I would add on and say: don't underestimate the physical toll of having a job
based on typing at a desk. Your back, hands, wrists, arms, hips, and probably
more can take a big toll directly from performing your job. If you're not
careful to avoid stress, burnout, etc, then you're also directly or indirectly
inviting huge risk to your heart, weight, mental health, and more.

Drink lots of water. Go to the bathroom. Have little walks or stretches in the
office, at least at your desk or in your chair. Go for a walk after dinner. Do
some light exercises at home if you can't walk at home. Sleep, sleep, sleep.

------
boyter
Start building your career so you have job security now. This means doing
things to eventually move into management or doing projects/blogs/postcasts so
that you stand out.

When resumes come across someones desk being a generic developer is not going
to help, and it gets worse as you get older. Having something that you can
show off even if its just a collection of blog posts about how you built a
simple CLI tool using Nim will make you stand out.

Work on your soft skills. Being able to communicate and get your ideas across
is more important then being able write the best code in any organisation. It
will make you stand out. Learn public speaking and show what you have done. Be
your own champion because its rare for someone to do that for you.

Lastly, learn some new technology and write posts about it. You will become
the expert in it if you do this at the right time and frequently. This will
open up new opportunities.

------
bunderbunder
Hands off the keyboard.

There's a lot of learning to be had in taking the time to read and understand
others code, in taking the time to really grok any brownfield system that
you're working on, and in spending some time with the documentation.

There's a lot of work you can save yourself by taking the time to assemble a
clear plan of attack before you start hacking.

(And if you're doing BDD, writing Gherkin files counts as hacking.)

There's a _whole_ lot of rework, wasted effort, and end-user aggravation that
you can save by really getting to know the business domain you're operating
in.

------
noufalibrahim
Learn to be useful to the organisation where you're working. Don't just be
about upping your own skills and stuff. Being valuable to the person who's
employing you is what makes your progress in your career.

Learn to be a professional. Basic things like showing up on time, being a good
communicator etc.

~~~
rubber_duck
>Being valuable to the person who's employing you is what makes your progress
in your career.

More importantly learn how to be recognized as valuable. It's better to appear
valuable without actually being valuable than being valuable but not
recognized, and often you don't even have a good idea what's valuable in the
bigger picture on your own so accepting others valuation can help you from
being stuck in your bubble.

~~~
shredprez
It looks like this comment is being downvoted because it appears to endorse
being deceptive.

I’d like to chime in and second the sentiment in slightly different terms:
value is not inherently visible. You can waste a lot of time contributing
significant invisible value to a company with no recognition or reward. On the
other hand, you can provide a small amount of value and receive significant
recognition just by making that value as visible as possible.

If you’re looking to have your value recognized, you need to commit energy to
making it visible. This means different things in different roles and
organizations, but it’s a critical skill to develop.

And it doesn’t just apply in business relationships! Learn to make your value
visible; it ensures the energy you put into anything is appropriately
acknowledged.

~~~
bluGill
If you don't have the personality to market yourself keep yourself in a
position where you contribution is obvious.

Working on a self directed project that makes tools for other developers can
be fun, but if you can't sell the value of that work you should stay on a team
that generates obvious features for paying customers. (which is to say work on
projects where marketing will sell your work, this indirectly outsourcing
making yourself visible to marketing)

------
perlgeek
Say "yes" to new challenges, even if you think they are over your head.
Everybody feels a bit of imposter syndrome, so don't let yours stop you.

~~~
1_player
There's no cure for impostor syndrome.

I have 13 years of experience, CTO and lead developer at my company and a part
of me always thinks people are way overvaluing my skills.

You just learn to ignore it, but it never goes away.

~~~
ancarda
Are you sure it needs to be "cured"? Lately I have been thinking that it's a
blessing in disguise; a painful -but effective- motivator to improve and seek
out new skills and more knowledge.

Yes, it comes with a side of depression, and that really sucks, but I've found
if I'm deep in some tech I don't know, it doesn't seem to affect me nearly as
much.

Could it be jut us getting restless? The feeling we haven't learned anything
new or faced any new challenges lately?

~~~
1_player
> Are you sure it needs to be "cured"?

Nah, as you say it is a blessing. And I wouldn't trust anyone who thinks
they're underrated or they know "enough" about anything.

> Could it be jut us getting restless? The feeling we haven't learned anything
> new or faced any new challenges lately?

I bet one could win a Nobel prize for breakthrough research and still feel
like a fraud. "Ugh, did those idiots really give _me_ a Nobel prize for this?
What were they thinking?" :)

------
bla2
Don't self-destruct. This may seem obvious, but surprisingly many people get
this wrong. There will be moments where you have incomplete data on some
situation, yet feel strongly about it, and have a strong urge to do some
symbolical career-limiting step as a reaction -- for example, threatening to
quit over some minor technical decision made by someone more senior that even
turns out to be correct a few years down the line, or leaving a product that's
on an exponential growth curve because you don't like to see the team changing
as it grows (this is valid concern, but there's also significant upside to
being an early member of a successful product). If you're in a situation like
this, it's usually a good idea to wait a month or two before doing anything;
usually the urge is over by then.

~~~
abraae
Related - hang in there (sometimes).

When things get their craziest, when entire teams are getting fired, that's
sometimes when career opportunities open up and massive advancement can
happen.

------
billman
Find a mentor. I was lucky enough to have a couple more experienced developers
take me under their wing when I was new. I learned so much from them. This
idea of mentorship has fallen out of favour, but I now understand "there is
nothing new under the sun".

~~~
andrewflnr
How does one actually do this? I have a hard enough time finding close friends
of any kind. And mentorship is a pretty big thing to ask of someone.

~~~
rc-1140
You don't. One thing I've noticed is that mentorship is one of those things
people like to toss about as well-meaning advice, but it's an empty suggestion
more than anything else. Realistically, what you can do is make an effort to
join some kind of programming e-community that's more intimate than HackerNews
and integrate with that community over some time, and then ask them for
advice. You can find a language-specific Discord/Slack/Gitter/IRC channel,
integrate (lurk, then post, become a known quantity), then ask more specific
career-oriented questions.

~~~
sodafountan
This.

In my first two roles I found that more senior level developers gravitated
towards mentoring me anyway. I didn't really even have to seek it out, usually
just getting in the door and humbly admitting to yourself that you don't know
as much as you thought you did is enough for people to want to share their
knowledge with you.

Don't be afraid to ask questions in the workplace when you're new, that's the
only cardinal mistake you can make, the mentorship will come automatically.

------
uptown
Beyond software development, focus on building relationships with the people
you work with at your company and in your industry. This will pay dividends
throughout your entire career.

------
tibbon
Do not try to understand _everything_ in order to do _something_.

Yes, understand principles, but don't get frustrated because you don't
understand everything from the silicon up to the photons coming out of the
screen. You'll never understand it all. Try to understand more, but don't try
to understand it all. No one understands it all.

I've seen this paralysis stop so many junior developers in their tracks. They
beat themselves up trying to get it all before doing anything.

I'm gonna be real; I have only the vaguest idea how the VM works in Ruby,
along with it's garbage collection (also, they keep changing it for the
better). Yet, I've been programming in it for almost 10 years on a daily
basis. I don't need to know this in order to setup some validations in Rails.
Sure, it's useful when you hit some problems, but not critical for most work.

------
vmlinuz
Unless you are in academia/research, your job is not to produce software - it
is to solve customer problems, add customer value, and help your team-mates
and wider colleagues. You should be able to trust your colleagues on the
marketing and product side of things, and while you should be honest with them
about tech limitations/requirements, you need to be able to work with them to
deliver product.

~~~
maxxxxx
But to have a career you also need to pad your resume with the right
buzzwords. Just solving business problems without considering your resume is
good for the business but will make it very difficult to advance your career
if you are an engineer.

------
alanfranzoni
Most valuable skill that wasn't yet told: learn to help yourself. You won't
always have a mentor, or formal education on a subject. The ability to succeed
despite external support is basic.

Don't fall in love with a random company, expecting reciprocation; wait for
the company to show love to you. If you do an astonishing good work and the
company doesn't reward you, pull back, do "normal" work, then look for another
company. Most companies either show their appreciation quickly and regularly,
or never.

------
daviddumon
Don't chase money, only focus on doing hard things that scare you at first
(think: at the limit of what you're capable of), then change when you're done
learning. Iterate for > 10 years.

------
zinckiwi
Start off by going deep, not wide. You'll pick up other languages and
technologies over time. Pick a stack that appeals to you and focus on it for a
while, learning its idioms and best practices and improving your development
fundamentals.

~~~
1_player
Good advice, mine is somewhat opposite :)

Never, ever, stop learning. Don't feel too bad if you can't find time for a
personal project like everybody else seems to have. Just make sure you are up-
to-date with the hectic changes in the programming world.

Every single time you're on HN and you're reading an article about Kubernetes
while you're just a frontend web developer expands your horizons and advances
your career.

And when you know something about most things, with some specialisation, go
freelance and expand your skillset and knowledge further.

The moment you stop learning is the moment your career crystallises and dies.

~~~
rejschaap
Don't overestimate reading an article about Kubernetes. It creates awareness
of the concept and what it could offer, but that is not the same as going
wide, it is too superficial.

------
jrvarela56
Understand key concepts in the (web) framework you are using. By sticking to
patterns defined in the framework, you'll save a lot of time/confusion and
prevent easily avoidable problems that accrue debt well into the future.

Example: Junior is confused by where to put a new file/module/function in a
frontend app and the app is built with Angular. Angular has Models,
Components, Directives, Services, etc (I don't really use the framework, but
same applies to Rails with MVC, Concerns, /lib, etc).

Learn your framework's constructs so you can frame your solutions in terms of
the frameowork. You'll be more productive by reducing the scope of your
decisions. Downside: you won't be able to find the 'best' solution to your
problem - you are constrained by the framework's model of how a webapp should
be built. This is ok, you are learning the ropes, so an increase in
productivity is worth the constraint in freedom to choose.

First, imitate and understand why the framework does these things and what
problems it means to solve. Once you've seen enough of these patterns/opinions
(hmm maybe binding the view to a model manually isn't such a good idea, i've
been forgeting and causing memleaks - hey Backbone days!) and have real life
examples of where the patterns present problems, you'll be able to
improvise/tweak/decide-yourself.

------
andymoe
Never call yourself a junior software developer - fight to keep “junior” out
of any title.

Read books/practice software design patterns and learn how to write tests.
(Unit, integration, end to end)

~~~
aphextron
>Never call yourself a junior software developer - fight to keep “junior” out
of any title.

I'd second this. "Junior developer" is generally just used to pay developers
less.

------
kodablah
All that code you write for the man you'll never see again when you leave.
Limit your pride, but not your quality of work of course. This includes
limiting overwork. If your financial situation and the market allows for it,
find a job that is not over taxing, and if you're a programmer by hobby and
have the time, write some open source stuff. Aside from career benefits, it is
fulfilling to review code you wrote in the past instead of just corporate
memories of it. It's extra rewarding if you're like some people that, while
you improve, your past code is still of very high quality. If you're the type
that relishes leaving a legacy, just be mindful of its visibility.

------
gpderetta
Good enough is better than perfect. It is also way better than 'not yet done'.
Always have targets in mind. Even green field explorative projects should have
targets. Good engineers ship.

Abstraction and encapsulation is overrated. Premature generalization is the
root of all evil.

Knowledge is no substitute for experience.

You cannot google what you do not know it exists.

~~~
pmoleri
I like these, I would add:

Don't decide too early. If you can postpone a decision that doesn't delay your
overall work, then postpone it. You may have more data later to take the right
decision.

Don't optimize too early (premature optimization). Always try first the
simpler approach, you will finish earlier, get simpler code and find out that
some minor optimizations or not at all are needed. You should always check
this with real world data / scenarios.

------
vinayms
1\. Don't blindly follow advice of "experts" you read.

2\. Don't write clever code, write readable code. Participate in code golf or
obfuscation contests to scratch the itch if you have one, but keep it out of
production code, even if its a private project that you will never share with
anyone; it will save you from yourself.

~~~
busterarm
On point 2, I think it's very possible to write clever, readable code.

I think Rob Pike's 5 Rules of Programming[1] are better advice here -- in
particular rules 3 through 5.

[1]:[https://users.ece.utexas.edu/~adnan/pike.html](https://users.ece.utexas.edu/~adnan/pike.html)

~~~
Skrillex
I think a lot of the time, we use "clever" to mean "obtuse, unreadable, and/or
obfuscated" when talking about code. The positive version of that word is
"elegant", I think.

------
apeace
Program in multiple languages.

Try frontend, backend, write random Bash scripts, try multiple paradigms, try
every language out there. Try multiple databases too. Don't just write toy
stuff, write something substantial that takes you 2-3 weekends to complete.

All of the best developers I've worked with have mastered at least two
languages, if not 3-4.

Will you necessarily use all that in the field? No, you might end up at a
Python shop and decide you love programming Python. That's fine.

But you will gain so much perspective on what is possible in programming, and
avoid getting stuck in the idioms of certain languages for the rest of your
career. It will give you a great design sense. It will give you the ability to
dive into any problem, in any language, and be successful.

------
vnorilo
A bugfix is not done when the bug disappears. It is done when you understand
why it occurred and why it no longer does.

~~~
ThorinJacobs
+1 and extra credit if you arrange so that it never occurs again. (Could be
adding tests, could be improving communication to faster identify requirements
gaps, etc)

------
betageek
Learn how the debugger works for whatever language you use. You will be very
tempted to just use logs as it's way easier and debuggers seem intimidating,
but take a day out of your schedule to learn the debugger. When you really
have no clue what's going on in your code there's no substitute for being able
to stop your program mid run and inspect it's state interactively.

~~~
adavis321
This is absolutely true, but it mostly applies when your code is in
development. Inevitably you will be asked to troubleshoot problems in
production. So you'll need to learn how to read and understand log files. You
should also learn how and when to log actions in your program.

That last sentence is part of my piece of advice: Try to add stuff (comments,
logging statements, etc) to your projects that will make things easier in the
future, either for you or other developers.

------
axpence
Two things:

1- Find solace in the fact that "senior" engineers often spend a significant
amount of time searching the web/stack overflow just like you do.

2- Have respect for the code that came before you. Be generous when passing
judgment on architecture or design decisions made in a codebase you've
adopted. Approach inheriting legacy code with an "opportunity mindset".

------
pjmlp
Improve your soft skills, work is more than just coding, don't become attached
to technology stacks, care about the team not so much about the company.

------
scarface74
Never accept the title of Junior Developer.

[https://daedtech.com/junior-developer-never-
accept/](https://daedtech.com/junior-developer-never-accept/)

------
toast0
On the technical side, learn how to read other people's code and debug things.
At the junior level, when you thing things are broken, they're probably not,
but the skills you build reading and proving that the other stuff works will
come in handy as you progress and you do find situations where the frameworks
you use, and the languages you use, and the operating systems you use are
broken.

Learn to tear down abstractions instead of building them up. As a junior
developer, it may be hard to get acceptance for removing layers, but add as
few as possible. Somebody is going to come through later and need to
understand what you've done, when the stack is deep, that's much harder.

Don't trust other people's code to do what the readme says. If anything claims
it's lightweight, count the lines of code and see. If you use other people's
code and it's broken, it's going to hurt your users and you're responsible.

On a people skills level, learn how to disagree without being disagreeable.
Invite people to share their reasons for things with real questions, and
listen to their answers -- while they're sharing you can discuss why to do it
their way vs the way you want to do it. This is a good practice for when you
are the senior person instructing the junior person as well. Often the senior
person is going to make the decision, but having a discussion about it can
make it easier to accept.

Don't do this for everything though. Choose your battles, don't be the person
who fights everything; unless you're getting good results and people are happy
changing everything.

------
davedx
Learn multiple programming languages. It will truly expand your way of
thinking about solving different problems.

Conversely, don’t spread yourself too thin. Try a lot of languages out then
narrow it down to a few you find interesting and useful, then focus on
learning those few.

~~~
Rooster61
I'd expand on this by saying that one should learn to program, not to simply
code. This sounds silly at first glance, but what I mean is that if you learn
how programming languages work, and truly grok what is going on under all that
syntax, you'll find it's much easier to transition to other languages as you
already understand the conventions at play (unless you are switching to a
completely different paradigm e.g. OOP to functional).

This is one of the things that is dangerous about these code bootcamps you
see. They are taught enough to write cogent programs for a given language, but
the underlying bits and pieces of what make software tick is left out. There
simply isn't enough time to truly learn the craft in a 6-8 week course.

------
btschaegg
I've got so many :(

I haven't seen this one so far (but haven't yet read all comments):

Whenever possible, try to avoid bugs. But, even more importantly: When given a
bug report, FIX the damn bug. Don't:

\- Shrug, mutter incomprehensible things and wish the person with the bug
report goes away (yes, I've seen that. It infuriates me.)

\- Say "that's not possible" (cf [1]). It is. It happened, no user makes this
stuff up for fun.

\- Say "that doesn't happen on my machine." Well done! Now make sure it
doesn't on all the other ones, too!

\- Say, "well, if you had _configured_ it right,...". That's also a bug: Your
documentation sucks. Fix it. Also make sure impossible/nonsensical
configurations are _visible_ (best done during startup, for example).

\- Avoid commenting on the report/contacting the author because there's not
enough information. Tell them you need more, what they must gather and how. If
you tell everyone the same things, write a HOWTO and link there.

\- Ignore bug reports. Valid reasons you're not fixing a bug are 1) you're
currently busy fixing another, more important one or 2) you already understand
the bug completely and have discussed the tradeoffs involved with others
(write a WONTFIX with sound reasoning, please).

To sum it up: Be helpful to your users/admins/etc. Don't be a "Code Monkey".

[1]: [http://plasmasturm.org/log/6debug/](http://plasmasturm.org/log/6debug/)

Edit: Formatting, reference to 6debug :)

------
BIackSwan
I am writing a book specifically for these. But focusing on soft skills.

Its called "self.debug - An Emotional Guide To Being A World Class Software
Engineer" \- you can download it here (its free) -
[https://leanpub.com/selfdebug](https://leanpub.com/selfdebug)

Feel free to provide feedback on twitter to me.

------
ConcernedCoder
Invest 10% or more of your gross pay into a low cost index fund. Do this
without fail for your entire career.

------
Noe2097
Never Ever Stop From Learning. The skills that you have now may be top notch
and covering all of today's trendiest technologies; but in possibly less than
5years, most of these will be outdated, and your expertise obsolete.
Specialize yourself, but do it everyday, on everything - try new technologies,
feel free not to adopt them in your daily job, but try them. Keep in mind that
every year, new guys come out fresh from school and will be as in sync with
the technology landscape of that time as you are now - and you do not want to
lose to them because you never took 1 hour to try the then-Docker - you want
to be able to criticize the then-Docker because _you_ will be able to compare
it to the past things that you will have already encountered, enjoyed or
suffered from.

~~~
smt88
To go along with this: if you don't leave your comfort zone regularly, you're
not learning and you're falling behind.

------
sirsuki
Please please study the tools and the principles you use. No schooling will
offer these things you learn then through experience. If on your own then that
takes a long time. To expedite find rules like Sandi Metz's rules and
S.O.L.I.D. principles, Learn OOP patterns and code smells. Don't worry if you
don't understand why these rules and principles are in place just follow them.
You'll eventually get there and the code you produce will not cause
catastrophes later on.

But if anything this simple rule is the best: K.I.S.S. (Keep It Simple and
Small) Make small things. If you ever find yourself saying "do this and then
do that" your talking about two things and make them two things (separate
functions/objects) and name them.

------
sizzzzlerz
Respect your co-workers. They may not be as talented or knowledgeable as you
but learning how to interact with a diverse group of people will pay dividends
down the road in ways you can't begin to imagine. And, above all, stay on the
good side of your department admin.

------
jypepin
Don't be scared of going into reading source code of libraries/frameworks you
are using to understand how things work. The code will often be simpler than
you think and allow you have a better, deeper understanding of how things work
and empower you incredibly.

~~~
AndrewOMartin
Also don't be scared if you arrive at some source code and can't make head nor
tail of it. Given time and enough attempts you'll start to be able to find the
info you need, but for some projects it'll never happen. :)

~~~
jypepin
Yes also true. Some project actually have very bad source code, but in general
it's often better than expected!

------
ajcodez
Learn sales, marketing, design, basic accounting. Basically learn everything
tangential so you know _why_ you are writing code not just _how_ to write
code. It’s a means to an end. It could be as simple as reading books or as
intense as taking online courses.

~~~
ajcodez
Also - Learn how to set up and configure servers not just how to write code
but how to run code and keep it running. If you know how to use basic programs
like SSH and NGINX it can only help you.

Also - I have been coding for 10 years now (as of September). It’s interesting
to see as I gain experience the biggest differences looking back are (1) I
choose to use more git branches and release 1:10 ratio smaller commits. (2) I
try not to ever go back to “refactor” or clean up code and instead spend time
on changes to accomplish the next feature or bug fix. (3) I never plan ahead
and think “what happens if ...” instead focus on the present. In reality the
future often never comes or it looks different than expected.

------
starikovs
1) If you're not a native English speaker, always improve your English. 2)
Start your open source side project and work on it in your spare time. 3)
Improve your skills by reading books and attending online courses. 4) Change
your job/project every year.

~~~
highstep
re: 4) - if your CV has a new job on it every year, I would be much less
inclined to interview/hire you. After all, 1 year in is when a developer
really becomes valuable to an organization.

------
gwbas1c
It's not about you.

When seeking a job: It's not about you. It's also not about the company you're
working for.

When improving the ugly code in the job you just started: It's not about you.
Don't argue about silly things like brace styles.

------
Dowwie
As Pink Floyd said, "all you touch and all you see is all your life will ever
be".

The more fond you are of your tools, the less likely _you may be_ to try
others. Don't develop preferences too quickly. Try not to emotionally invest
yourself in decisions you've made about languages, libraries, editors,
operating systems, and other technologies that you will spend thousands of
hours with. Technology changes so quickly that you can easily find yourself
mastering a local Maxima where others have already left and moved onto higher
ground. Try new technologies and adapt with the times.

------
kylestlb
1) Try to learn as quickly as possible which parts of the code are critical
infrastructure and which parts of the code don't warrant perfection. I know
this is probably difficult in an environment where every single character in a
PR is heavily scrutinized, but time is a finite resource, and you need to be
very careful not to overengineer things are not critical or will be replaced
eventually. This was one of the hardest things for me to learn. Perfection is
the enemy of the good.

2) Learn to love working on legacy codebases. This will happen everywhere you
work. You will rarely (if ever) have the opportunity to start from scratch. If
someone asks you to use an existing piece of code, and you decide to re-write
it because you don't want to take the time to understand what's going on, you
will A) appear to be anti-collaborative and B) reinvent the wheel, thereby
wasting time. Obviously, there are scenarios where re-writing something from
the ground up is necessary, but make sure all stakeholders involved agree and
that you can estimate it correctly.

3) Always try to coax out as many details from designers and product
managers/owners wherever possible. Perfect requirements will never exist but
you want to be equipped with as many use-cases as you can before you start
hacking on something. This may sound a bit waterfall-ish, but PMs and
designers are not omniscient creatures. There is almost always some sort of
gap that you may be able to help identify.

4) Don't be a dick, because there will almost always be someone who knows more
than you. This applies to comments in PRs! Even if the entire company treats
you like a god, that does not give you the freedom to treat others like
worshippers.

5) If you are asked to estimate how long X will take, DO NOT give an answer
until you have enough details so that you can make a reasonable estimate. If
they force you to give one, pad it 2x or more depending on how much you don't
know about what needs to happen for the task to be marked 'done'. Even better,
ask them for a separate fact-finding task (spike, POC, or whatever you want to
call it) so that this can be more easily tracked.

I could go on forever but these are some of the more non-obvious things I
don't hear talked about enough.

------
c2h5oh
Be happy about working on things that are feel way to hard - it means you're
learning fast.

Write code for fun. Find a hobby away from computer for sanity.

Consider the risk of burnout - even with great mentor and challenging work a
toxic environment is not worth it long term.

Care about ergonomy of your workspace now - adjusting height of monitor costs
you nothing, good keyboard and wrist rest cost less than you make before
lunch. Carpal tunnel, ulnar neuropathy and back problems will start hitting
you and your friends when you are teaching peak of your career and are no fun
in general.

------
fcbrooklyn
At some point, you will be confronted with a problem (a bug most likely), and
you think it is beyond your ability to fix. Do not give up. If you can't
figure out what's wrong, figure out what isn't wrong, and keep figuring out
what isn't wrong. This may not feel like progress, but it is. Do not go to
your dev lead and say "this one is beyond me". Say "I'm stuck, but I've tried
X, Y and Z, and it's none of those things. Do you have any ideas?"

Biggest issue I find with developers right out of school, is that they often
feel ok throwing a problem over the wall to a more senior dev. The truth is,
all of us are confronted with problems we don't know how to solve. That is the
job, but if we don't solve them, who will? You will not magically discover an
ability to solve impossible problems and diagnose inscrutable bugs. But if you
don't give up, and you fight your way through these problems again and again,
you will develop confidence, and the instincts that allow you to do it a bit
quicker next time.

On a related note, do NOT rejoice when a bug you've been struggling with
suddenly goes away (another thing I've seen many times). Nasty bugs "going
away" is one of the worst things that can happen. I promise you, 90% of the
time it's coming back. And it's coming back at the worst possible moment, and
possibly in a less friendly form.

------
bastijn
Ask questions. Ask them all the time. Never refrain from asking a question
because you feel you should know the answer.

The mistake I see all the time is juniors nodding because they fear letting me
know they don't understand is a weakness. A sign they do not master the
language (in fact I see this with most people). Always ask questions. It has
multiple advantages: (1) it answers your question so you can understand, (2)
it shows me you want to understand the topic under discussion, (3) it helps me
explain the topic by guiding me to the parts you find complex, (4) the nature
of your questions shows me how much you understand of the topic

Being able to stop someone and ask what a particular term or concept means is
a super important skill for any engineer. It does not list you as a fraud, it
lists you as a great learner. Remember that. Always.

Now, when asking questions ask the right questions. There is enough material
here for me to provide just two links and let you google for the rest. [0][1]

P.s. Bonus reason: Assumptions are the mother of all f*ckups. Ask to verify
things you think you know!

[0] [https://jvns.ca/blog/good-questions/](https://jvns.ca/blog/good-
questions/) [1] [https://hbr.org/2018/05/the-surprising-power-of-
questions](https://hbr.org/2018/05/the-surprising-power-of-questions)

------
arountheworld
Don't agree to work for peanuts. Young developers are easy target for
"startup" or predatory corporations as they can do mindless coding for hours
and if you throw in free pizza on Fridays, they'll work day and night for
almost nothing. Once you get burnt out you get replaced with another young
wannabe developer. But you'll have damaged health and no savings. If offer is
low and you think you'll get experience - you won't. Just look more for
something that respects you.

~~~
asdffdsa321
Nonstarter, obviously no one wants to work for peanuts, and it's easy for
people with established careers to give that advice but not very useful for
most younger people with little resources

~~~
arountheworld
My advice then would be to live frugally, do personal projects and save and
save, then leave the company if you have 3-6 months of living covered. You can
spend more time on getting your CV right and searching for offers. If
recruiters and/or companies see you have a company known for paying peanuts,
they'll unlikely to hire you unless they are the same predatory company.
Nobody wants a burnt out employee that won't respect him/herself. That's why
you wouldn't put such company on a CV and should have a good personal project
to show instead for that time frame.

------
baud147258
If you can, don't hesitate to ask senior dev for help (but only once you've
done your own research). In that case, knowing how to explain what's the
problem, in the context of what you are trying to do (the context is important
because of the XY problem). Communication with non-dev and person outside your
project is important, usually those person will either control the budget or
be users and stakeholder. Admit your mistakes, especially when they affect
other persons.

------
Insanity
Learn the tools that you'll use to develop software. Becoming proficient in
the tooling will help you greatly with the actual development.

Some things you can do for example:

\- Using linux? Learn to use the CLI

\- Learn to use git/svn/... (whichever you use at work)

\- Get comfortable with your IDE (shortcuts, customize to your liking, ...)

\- Learn to use a profiler (JProfile, ..)

Those are some pretty general things but they'll help you in any job where you
write code.

The tools are (imo) just as important as knowing the language you use.

------
etbal
\- Be able to delete all your code without feeling sad about it. It's freeing
to be able to delete code if a better solution presents itself. Generally
these things can be found out by talking to business people and other
developers, by having a session where you draw the proposed solution out on a
piece of paper or by just iterating through it yourself.

\- Confidence comes from trying, and failing, and trying again.

\- Burnout is real. Know when you are close to it by knowing what triggers
your anxiety and stop. Having the ability to remove yourself from a stressful
situation, even if just for an hour makes all the difference .

\- Test your steps. If you can write code to test your steps then it's great
but most of the time a simple browser reload/button click or command line run
action with verify if your change works will be good enough.

\- It's fine if you don't know. Having the ability to ask for help will mostly
be met with respect.

\- You are not defined by your code as a person :)

\- Theoretical pureness mostly gets in the way of solving an actual problem
because of the endless debate it sparks in a team. If your goal is to write
code that is readable for someone in the future then it doesn't matter what
design pattern you use. Computers are fantastic at understanding code. Humans
however need some help.

\- Try and clean up as you go. Like your home, if the dishes pile up too much
it becomes unliveable.

\- Lastly, learn how to understand legacy code. It's a fantastic snapshot into
the way the business was thinking at the time and to see it evolve and be that
change is a privilege to be part off.

------
dba7dba
Good managers are rare.

Don't trust your manager(s) that they are going to lead/manage/mentor you in a
way that will really help you. They are not.

If I allowed myself to be really cynical, they are mostly out for themselves.
Most will have no problem using you or even throwing you under the bus to get
themselves ahead (or protect their own jobs). And this involves things like
having you do things (aka work with less valuable techs) that they don't want
to waste their time with. That is what `delegation` is.

But don't worry though. Most of the time, they have little time left to think
about ways to take advantage of you. They are just busy managing their own
jobs, your fellow team mates, and their own bosses. Oh, and figuring out how
to beat fellow managers. They have their own family/retirement-plan to take
care of. They don't have much time left to manage you after sharing extended
pleasantries with their own bosses.

And the more successful your manager seems, the more guarded you should be
about them using you to their advantage. I've been around and of the bosses I
had over me, two are now in high level position (VP) at really well known
brand name companies in US. Because we were in smallish startup shop with
cubes/offices near, I was able to observe them from nearby. Both were really
good at pleasing higher ups (not necessarily through excellent work but with
friendship), have no problem with pushing around those under them, and just do
good enough job of actually managing the team.

Also, don't settle. Don't settle into a role that you feel comfortable. If you
feel comfortable at a role, it's time to move on. And time flies. Make most of
it.

------
jstankewicz
Don't set yourself on fire to keep your company warm.

------
ankit219
A bit late to this thread, and this is coming from someone who used to code,
but does not anymore, atleast not actively.

Avoid what is known as 'Somebody Else's Problem Field' behavior. (Here is the
link:
[https://en.wikipedia.org/wiki/Somebody_else%27s_problem](https://en.wikipedia.org/wiki/Somebody_else%27s_problem))

What I mean to say is, a lot of times developers have an attitude which says
"I'm done with my work, now if its not working, it's somebody else's task" or
variants of that dialogue. As a developer, I understand and concur with your
position that you might have done all the things right, but as a team, you are
not helping matters by saying that. Volunteer to check your code, do more, and
try to figure out where the problem is, like what input you are getting, what
is the output, where is the code failing. the more you help in these cases,
the faster the things get done.

This is also a common behavior, when someone asks you for a data or a piece of
code, and you send her a straight forward export/import in the raw format.
Occasionally, that might need the other person to do a lot of clean up and
other operations, (with a bit less context), and would have been easy for you
to do in the first place. As a developer I did that a lot. On the receiving
end, this is one of the most frustrating things, since I need to account for
it in my tasks beforehand. (Example would be a simple dataset, given to me at
SKU level - cos requires a straightforward query - while if extracted
aggregated, would have taken 5-10 more minutes for the developer, but now the
asker is expected to spend sometime cleaning up and aggregating that data set.
Might not always be this, but I hope you get the point.).

my 2 cents.

------
mmagin
Learn how to understand who the "customer" of your software is and how to
deliver what they need. Learn what you're inherently good at and not so good
at (and develop strategies to work around your weak points.) Learn that code
reviews are discussion of how you did something, not an attack on your ego.
(or at least they shouldn't be.) Find mentors you can trust.

------
hakanito
Some great advice in this thread already. I'd add learning to use git from the
command line (together with the concepts of a rebase, a merge etc), it will be
useful in every single CS job.

Figure out what parts of the stack you're more passionate about. This may
shift over time, but if your working on things that you truly think is
interesting it will keep work from being work.

------
reality_caster
Spend time with the code before you ask for help. Try different things, break
things locally and understand how the code stands in a bigger system level
picture. If you are in a good organization, they will support you breaking
things in staging as it will provide them a better picture of code reviews
etc. So break things and learn fast.

Most importantly, junior software engineers and interns often complain that
the work they do is not impactful - it may seem that those around you are
doing impactful work (and it might actually be true in a very few cases), but
don't let this effect your peace of mind and not let you give your best. Every
work you do must show a characteristic of your quality. Engineers must be able
to provide anything in their field, at all levels of their stack, regardless
of how important they feel their work might be. Always respect your work and
be grateful for getting an opportunity for working on it because someone did
not get that chance.

------
breckenedge
A senior developer told me early on that all software is compromise. Thinking
back to that has often saved me when I realize that I'm trying to find a
_perfect_ solution. There is no perfect solution. Also, read books, especially
The Pragmatic Programmer. I finally read it this year as a Sr. Developer and
there were some great nuggets of wisdom.

------
poulsbohemian
Find a hobby. Interesting things happen at the intersection of technology with
_other things_ , so find other interests apart from software. Technology
skills, management skills - these are table stakes. Perhaps even more if you
take the generalist career path, having some additional domain knowledge or
value-add that you can bring will be important.

------
spondyl
It's tempting to feel like asking numerous questions can be "bugging people".
Unless they tell you "Sorry, I'm busy today from X to Y" (they should if they
respect their own time), look at it as providing the opportunity to teach

It sounds silly at first but for those of us who like to share what we learn,
or think others aren't interested, we love it when anyone has questions for
us!

Don't be afraid of failing a lot either. Personally I've learnt a great deal
of things just because I tried to do nonsense things that failed and taught me
a lesson.

I first dove into unicode (and did a talk at a meetup) because I had this
absurdly stupid idea to make a program that "prints hotdog emojis every X
minutes". It didn't work but just asking "Why?" lead me to a lot of answers
and even more questions.

You never know when seemingly useless info comes in handy again (like obscure
modules in the docs for your favourite language)

------
bonsai80
Learn _why_ things work, not just how to make something work.

You'll probably have plenty of times where you know that "if I write this line
of code, this thing happens, and that solves the problem". Dig into exactly
what that is doing and understand why it works as it does. A lot of the time
this just means reading all the documentation (not just the 1-liner you can
copy/paste and move along) and source code of libraries.

A good exercise you can do is to open up some code (ask a coworker for a good
place to start), look at it line-by-line, and ask yourself if you know exactly
what is happening on each line. You probably won't know and that's your
trigger to go read up on something. From there you'll have great questions
that a coworker should be happy to talk about with you.

In my experience, new developers that take this approach of truly learning
(rather than just making things work) grow fast and impress the team.

------
every_other
As you start to gain some experience it can be tempting to think your
particular philosophy, framework, solution to a particular problem is the
right one. Over time, you'll find lots of you assumptions and beliefs that you
thought were beyond doubt change. Keep an open mind and don't assume you're
right.

------
quantummkv
Don't say no to work just because it is not using the stack/vertical that you
want to be in. Rejecting offers and jobs just because it is not in your
preferred tech stack/department/vertical is the worst thing you can do for
your career. I learnt this the hard way. Make sure you don't.

~~~
perlgeek
On the flip side, if you have tried a stack, and after half a year or so still
don't like working with it, it's no shame to look for something else to work
on that you enjoy more.

------
watwut
Never stop learning technical things. Also, learn to negotiate, learn how to
be organized, learn to prioritize. Both deadlines and requirements are very
very often negotiable and movable. Even if deadline is not negotiable, the
requirements typically have room in interpretation. Being dependable matters a
lot.

If you never say "that estimate is too small" then you cant blame manager for
assuming the estimate is good. Saying no is an option, learn to do it
politely.

Sometimes manager is pressuring you, sometimes he/she really just asked when
it is going to be done. Don't panic, answer truthfully.

You cant make up tomorrow or next week for time unexpected spent on something
else or just wasted. That is not how it works. Factor that into estimates
(whether formal or informal).

------
autogol
Socialize with people in your organization. Get to know people outside your
team, especially those from non-technical departments. Try to have lunch with
different groups in different days

Why:

1\. Chances are you'll meet very interesting people, with a background
different than yours. This is invaluable, in my opinion

2\. You'll understand how the organization works and how information
dissipates.

3\. You can learn about their jobs, and if possible, find ways to make their
jobs easier for them. Do someone a favor, they'll most likely return it.

3\. Networking can provide very interesting opportunities in the future

4\. You'll get perspective from outside the technology bubble

Physical exercise. If possible, try to do it at least 2 days a week. Besides
the obvious physical health aspects, regular exercise is a performance boost
for intelectual work.

Best of luck!

------
__exit__
Ask questions, no matter how stupid they may be. REALLY. Ask any doubts and
questions you may have regarding coding practices, implementation details,
technical workarounds, etc...

Even if the questions sound silly, which is what terrifies the most, just ask.
At my first job, I was too afraid of asking my teammates unless I came up with
some smart-sounding question.

Fast-forward a couple of years until now: I have a teammate who is quite less
experienced, and revealed me he does not want to ask questions because he
thinks it's a waste of time for the other person and/or he feels silly to the
whole team.

I attempt to mentor him and teach him to ask questions, no matter how dumb may
be. _We 've always been there_.

This leads me to another aspect: have empathy towards your colleagues.

------
MichaelMoser123
Always understand what you are doing, never accept advice like 'do it exactly
like this to be on the right side', in short: stay clear of vodoo. Learn
scripting to avoid repeating yourself, learn templates/macros or whatever it
takes to avoid code duplication (it takes an effort, but is really worth it).
Have some kind of document where you can write down your experience, what was
learned, what kind of problems you have solved - patterns keep repeating and
writing stuff down helps to be aware of these patterns. Try to learn reading
code - it's a skill of great value. Learn specifics of build tools as a lot of
time gets wasted if the tools are not understood

Be a bit sceptical of people who pass out judgement and advise

~~~
MichaelMoser123
On second thought I don’t like my answer any longer: your knowledge and skills
are conditioned on the environment where you were functioning/working. A
slight change of environment and most of your assumptions and knowledge is out
of the window.

What is important is a willingness and skill to learn new stuff; all else is
in a flux.

Also I don't like this distinction between junior and old hands; it can make
you complacent.

------
softwaredoug
Focus on a niche and specialize more than “software”. As a junior you have
some time to figure it out (but don’t take too long). Software is everything
these days, so if you can focus on a subfield you’ll maximize your future
earning potential and lifestyle. It’ll also help you stay technical well into
your career.

To do this, keep your eyes open for opportunities to go deep into something
interesting at your job and be the company expert on that topic. This is a
nugget of a personal brand. Then take this and expand on it outside your first
job. Blog about it. Speak about it. Create open source about it. Find the next
job that hires you for these specialized skills. Rinse repeat...

Worst case is you can still switch, or go back to just “software developer”

------
bluGill
Keep good notes in a form where you will remember you have them and look at
them.

Which is a fluffy way of saying when you tell someone at 4:55pm "I'm leaving
now but I'll get to it first thing in the morning", you actually do it first
thing in the morning.

------
tomelders
Write as little code as possible. But make sure that whatever code you do
write is readable.

------
edwingustafson
Try not to sound so surprised when your code works!

------
pacuna
Don't ask a colleague every time you don't know how to do something.
Investigate, learn how to debug. Building intuition is what's going to take
you to the next level. Also, try to not get stuck with same tools for too
long.

~~~
bashmydotfiles
To bounce off of this point - be sure to figure out the right time to ask
questions. I'm currently a junior programmer and I've been struggling with
this myself. Obviously, you shouldn't ask a coworker a question the moment you
don't know how to do something, but you also shouldn't be stuck on something
for a week without asking for help. It's all about balance.

------
SonnyWortzik
Start with the support backlog.

There is no better source of knowledge than solving software issues. You see
it all in that backlog. Deployment issue, build issues, bug fixes, feature
changes, merging problems, log files, web server configurations, DNS issues,
certificate installations, database errors, database updates, connection
issues, you name it. It is in there.

Once you feel comfortable with that backlog, look at the source code of your
application and you will then ask your self, WHY IN THE WORLD WAS THIs BUILT
THIS WAY?!?! you will find everything wrong with the application and that is a
good feeling.

Start with Supporting an application before developing it.

------
sanitycheck
Lots of good advice here already, I'll add two things:

1: Never trust a recruitment agent.

2: Don't be afraid to ask questions. I've had 30+ contracts in 18 years, and
I've lost count of the number of times I've been in a big meeting where some
manager or director is specifying something which makes no sense, and all the
other developers are just nodding quietly. It saves a LOT of time if someone
politely says "sorry, maybe I'm being a bit dumb, but I don't understand"
right there and then. 4 times out of 5 it turns out that nobody understands,
including the guy talking about it.

------
1001101
Know your tools. Be a good teammate - this is a team sport. If you're going to
do something more than once, automate it. Get paid for the lines of code you
don't write, rather than the ones you do.

------
Zyst
When trying to learn how to implement something, or fix an issue you have, and
you end up in the documentation: Read the documentation page for the thing you
found. All of it.

I know there is a lot of stuff you do not know, and it can be truly
overwhelming to try to stop, and read for 20 minutes when your parsing might
get you the answer you want in 1. But you will learn a lot more, and you will
start running into issues less and less frequently.

In the long run, it will genuinely save you time, and you will understand the
tools you are working with much more deeply.

------
dlevine
Start learning how to figure out what your customers want. At the end of the
day, it doesn't matter how pretty or scalable your code is if it doesn't solve
real problems. I'm not saying that you shouldn't learn how to be a great
developer, but a lot of great developers end up working for a series of
companies that build cool technology but don't do well.

Ask whether you can sit in on calls with customers, either prospective or
current. You will find out what they want, and whether your product is solving
their problems.

------
gfodor
Read books on programming and design. In today's world of stack-overflow-
driven-programming, just reading docs and non-clickbait blog posts make you
stand out by having more than superficial knowledge of things, but having
dedicated focused knowledge expansion through reading books that aren't
immediately goal-directed can accrue superpowers. It's exceedingly rare to
encounter a developer who exhibits the kind of breadth of knowledge that comes
from prioritizing focused reading time.

------
LolNoGenerics
Learning how to write decent software just takes time and comes with a lot of
failures in between. Good peers know that and you should too. But they will
often leave you with some easy stuff to get you productive and it is very easy
just bury yourself in this work. Try to observe what your seasoned peers a
doing, listen to conversations between them, ask questions if possible. Things
that happen away from keyboard is nothing someone teaches you in school, but
there is a lot to learn from that.

------
sizzzzlerz
Try and understand the big picture, not just the tiny corner you've been
assigned. Working in an iso-chamber is neither pleasant nor productive.
Understand where you fit.

------
umanwizard
Don't just accept the API you're given and throw your hands up when it doesn't
work. As far as is practical, understand how things work all up and down the
stack.

Writing some React code and it doesn't work for Chrome on Linux?

You should in principle be prepared to debug not just your own code, but
React's internals, the Chrome JS engine, and the Linux kernel itself until the
problem is identified.

Obviously that sort of thing is a last result, but you should in principle be
prepared to do it.

------
chrismatheson
Remember that working for someone else means that other person, who has th
means to take the risk has mad a calcualtion that there is more income
generated from your work product than the money spent on obtaining it. So work
exactly as much is reasonable and use the rest of your time and energy to take
the same gamble on yourself, out your extra effort into yourself & your own
bussiness India’s rather than someone else’s ( for negliagable reward)

------
g105b
Keep a daily log of the things you learn, decisions you make, and ultimately,
code you write.

It will be golden six months down the line when you're questioning your
career.

------
wicz
Read other people's code.

------
jerryclinesmith
A bit of self promotion, but I was interviewed a few years back on how to
become a software architect, I think its solid advice to any developer:
[https://www.roberthalf.com/blog/salaries-and-skills/how-
to-b...](https://www.roberthalf.com/blog/salaries-and-skills/how-to-become-a-
software-architect)

------
sheepybloke
I'm still a junior dev, but the difference between my successful and
unsuccessful peers are their tenacity and curiosity. Don't be afraid to ask
questions, put in the work to try the debugging yourself, stick with the
problems you encounter. But ask tones of questions, as there are often more
experienced devs who'd love to help!

------
baccheion
Programming is like articulating/verbalizing a thought. Increased verbal
fluidity = faster programming. Nootropics.

------
JensRantil
I've already written down everything I know in [https://www.quora.com/What-
are-the-best-secrets-of-great-pro...](https://www.quora.com/What-are-the-best-
secrets-of-great-programmers/answer/Jens-Rantil). I keep updating that answer
from time to time.

------
ovrkil
The company where I am employed the ideology is time an employee spends in
cube + salary paid + company resources used must produce maximum profits. So
the time a prospective employee takes to ascertain a problem and implement a
fix is far more valuable then the amount of times he/ she takes to solve the
problem.

------
amriksohata
Read the clean code book by Rob Martin and the head first design patterns
book. Both are musts for software engineers and Amazon top sellers for
developers. Other than that be like a sponge and learn transferable skills in
one or two mainstream languages, you can't go wrong with Java, c#, sql and
angular.

~~~
realharo
Do read those books, but don't take them as gospel, and don't be afraid to use
your own judgement.

Both have some flaws and highly subjective advice in them, and if something
doesn't seem to add up, it's very possible that there's a better way. Try
things out and see how they fit.

------
ovrkil
At the company I am employed with the ideology is the time an employee spends
in cube + salary earned + company resources must = maximum profits. So this
means the amount of time a prospective employee takes to ascertain a solution
is way more valuable then the times he/she takes to fix the problem.

------
eithed
Be nice to people. Accept other people point of view, but don't be a pushover
as well, try to form your own ideas and ways of coding. Be proactive - if you
don't have nothing to do, look at existing codebase and try to derive why it
is the way it is and what can be done to make it better.

------
sitkack
Explore everything early. Get rid of your preconceived notions of things and
just experience. Turn your judgement of things and others down a couple
notches so that you can gain more experiences. Work to understand systems and
people, there is so much to be gained from learning from others.

------
ninjakeyboard
Some foundational stuff I usually recommend: \- algorithms and datastructures
(princeton coursera course) \- functional programming will make you a better
developer \- "head first design patterns" is a book that will get you to
understand the heuristic of design patterns in OO fast

------
ovrkil
Where I'm employed the company's philosophy is employee time + salary earned
must = overall maximum productive results. When a prospective coders
interviewed the time spend debugging and recompiling takes precedence over how
many times he/she attempted to fix the issue.

------
spacecowboy
I would share the following principles to apply to your career (from my
martial arts studies):

Be Honest.

Be Humble.

Respect self and others.

Practice diligently.

Seek perfection of character.

And would also share the following quote from Hiroshi Saito (CEO of
Chateraise) which I came across later in life and thought it helps to change
your perspective:

Everything outside of me has something to teach me.

------
sys_64738
Robots are coming and so is automation. Programming opportunity will only
exist in custom projects but most companies want to use COTS solutions to not
beholden to contractors in the long run.

This change is starting to emerge and the programming opportunities for the
future will start to erode.

~~~
poulsbohemian
> most companies want to use COTS solutions

This was true 20 years ago too, and yet the demand for developers is as great
as ever despite more and more COTS type solutions available each day. I'm not
being critical of your viewpoint, rather I'd like to understand what you
believe has changed or is changing. Especially, I'm curious what role you
believe robotics plays in that.

~~~
sys_64738
Take Python which is a language with a continually growing number of
frameworks. Those frameworks take care of the majority of the grunt work that
developers have traditionally had to do. The API extensibility of those
frameworks it the modern COTS experience. Those APIs are all destined for the
cloud and the majority of your functionality will be consumed by those cloud
APIs. Your job as a programmer is merely to sow a few of those APIs together
to create a shim layer of functionality with a pretty user interface.

When you get to this level of simplicity then the human factor can be quickly
replaced. That's where robotics comes in.

------
jitans
If you use a compiler do not ignor ever ever the warning messages. Aim, from
day 1 to have a compilation warning free. Write code to be read by humans, and
do not ignore writing testing code, more or less you should have twice code in
testing than real code under test.

------
Mc_Big_G
Grind on leetcode until you can do any problem quickly. It's all that matters
for interviewing and you'll get a job making more than people with 15 years of
experience that can't leetcode but can create beautifully architected apps and
systems.

------
bcheung
Find a project you are passionate about that you can pursue on the side.

It can be both your portfolio and motivate you to keep pushing the envelop.

I do these short little exercises in programming to explore different
concepts. Usually make a rough POC for an idea or some kind of interface.

------
nemild
If useful, I asked a similar question a while back — with some great
responses:

Ask HN: Senior developers, what would you tell a younger you?

[https://news.ycombinator.com/item?id=13168798](https://news.ycombinator.com/item?id=13168798)

------
RickJWagner
Read as much as you can stand.

Draw lots of doodle-diagrams, then throw them away. Draw again.

Watch YouTube videos. Some people learn better by watching.

Above all, code a lot. If it doesn't make you happy, quit. If it does make you
happy, look for more ways to improve your personal learning style.

------
1f97
try to be autosufficient. if you have a problem, try to fix it yourself. try
googling, reading source codes if you have to. it's very annoying when people
come to me with questions that could have been resolved by doing 5 minutes of
research online.

~~~
pdpi
Inversely – and I've seen loads of people, myself included, with this problem
— learn when to quit and ask for help.

------
sp821543
Document everything someone teaches you. Having to be told twice is not ideal
for a jr. dev.

------
ovrkil
The philosophy of the company I work for is: make sure the hours spent in cube
by employee + salary earned = maximum results. So on interview a prospective
coders debugging time is way more important the times he/she fixed and
recompiled.

------
vinnymac
Write everything down. Even better commit the things you write down. Take
notes, document best practices, scribble on your hand, whatever you can do to
remember that obscure command that person executed that one time while you
were half awake.

------
aembleton
Ask questions. Don't be afraid to question something that you don't
understand.

------
specialist
Best advice I ever got was from a creative writing class:

Writers write. To become a better writer, write more.

But then I've always treated programming as a form of communication. Maybe not
literature, there's still beauty, awe, and whimsy to create and behold.

------
tmaly
Do not over engineer solutions. Get good at communicating with the business
side to find out exactly what they need.

Practice things like TDD to ensure you have a good set of tests that will
allow you to maintain the software for years to come.

------
loop0
My best advice would be: go to meetups, choose some languages that you would
like to work with and attend to as many meetups as you can. It's an amazing
place to meet like minded people and learn from theirs experiences.

------
capkutay
Stay a software developer as long as you can. Don't jump into management
prematurely. You'll miss the days where you used to work on interesting
technical problems rather than people problems and politicking.

------
fortunajs
from my experience:

don't listen to management team saying "this guy is the best developer I've
known" \- his code still might be crappy

put "solved" after the phrase you're searching in google

always have your CV ready on your computer

------
Alfwich
Read every line of code you plan to submit for inclusion into any project.

------
yumaikas
If you can, find a copy of "A Philosophy of Software Design", and read the
whole thing.

It'll give you a lot of higher level things to think about as you're diving
deep into your first tech stack.

------
hacknat
Work on things that are interesting to you, if you are bored for too long your
skills will atrophy. If you are interested in your work, being indispensable
to your company will be a natural result.

------
baccheion
Start learning about the following topics: public speaking, leadership,
health/fitness, sex/relationships, personal finance, investing,
business/entrepreneurship, marketing, and copy writing.

Where to live, what apartment to live in, where to work, who to become
involved with, what bed to get, etc.

Nootropics. Cognition enhancement. A multivitamin + D & K + chelated/TRAACS
magnesium supplement. Meditation and/or brainwave entrainment audio. Stress
management. Ensure quality sleep.

Nootropics that increase verbal fluidity tend to be great in corporate
environment, especially as it becomes clearer what leads to a promotion/raise.

Being promoted every other year (0 = entry, 2 = mid-level, 4 = senior, 6 =
staff, etc) is conservative/typical/traditional. Fast risers get promoted
every year. Move around, especially if your job isn't great or well-paying, to
maintain a pace.

Though an engineer, still network. Weak ties are better than deep friendships
when networking. Approach all as though they are friends. No need to let
someone draining waste your time. Cast a wide net, but choose wisely.

Don't let them work you to the bone. Startups fail 98% of the time (78% if BS
exits are included) and corporations typically don't care about you.

Your employer owns everything you develop on company time or using company
equipment.

Understand the business, users, and political landscape at your company. Avoid
getting involved in politics and gossiping. Commit to maintaining ethics and
professionalism, then set everything up such that it doesn't sabotage you.

People tend to be selfish, two-faced, and unconcerned about you. Smile and be
happy while remembering they'll likely stab you in the back with little
hesitation.

There's being irreplaceable and there's them knowing/thinking you're
irreplaceable. Only the latter matters.

Many years ago, it was estimated that 4% of executives/CEOs were psychopaths
(versus 1% of the general population). A study released in 2016 now puts the
estimate at 21%.

Read, read, read, read...

Avoid stagnating and blindly following whatever's said. Things change and the
world has little problem leaving you behind. Staying fresh/competitive can be
difficult, especially as many companies heavy-handedly try to push you into
the trap.

Take-home salary: 20% to savings (max out 401k even if just up to company
match), 30% max to rent, and 50% toward expenses.

house_price <= 3 * yearly_salary. 20% down payment. mortgage <= 2.4 *
yearly_salary.

Car: down payment >= 20% of car's value, finance period = 4 years, principal +
interest + insurance + license + registration + gas + maintenance = 10% of
one's gross monthly income. Buying without taking a loan is even better.

Ageism. Software Engineers have an expiration date. If not in management or a
founder/consultant by mid 30s, things can easily get difficult.

~~~
scarface74
_Ageism. Software Engineers have an expiration date. If not in management or a
founder /consultant by mid 30s, things can easily get difficult._

I find this to be a myth more than a fact - unless you care about working at
one of the cool hipster startups. Most companies don’t care how old you are as
long as you can code - I say that as a 40+ year old developer who agressively
keeps my skills up.

------
theshadowknows
If you’re the smartest person in the room then you’re in the wrong room.

~~~
eksemplar
This quote is so silly, and misused. It’s like one of those facts about
Einstein that you’ll see on Facebook.

For one, in this context, a junior developer will rarely be the smartest
person in the room. So it’s really terrible advice for the context.

I think it’s really terrible advice in general though, the places I’ve learned
the most is exactly when I’m the smartest person in the room, doing stuff like
mentoring or teaching.

In fact I do part time work as an external examiner at IT educations in my
country, exactly because they teach me a lot. I’m almost always the smartest
person in those rooms, but by evaluating i relearn/refresh things that I
haven’t touched in a while.

Aside from that, you’re almost never in a room where there isn’t an
opportunity to learn. Maybe you’re the best programmer in the room, maybe
you’re the best architect, but you’re very rarely the best at everything, and
the modern workplaces thrives the most from teams, in which everyone is the
best at something, because they become more than their individual sums by
cooperating.

~~~
dolessdrugs
In a non-technical environment, it is very easy for a junior developer to end
up the smartest person in the room as far as tech is concerned. Think meetings
with SMEs, PMs, or Sales.

~~~
TheCoelacanth
The statement is if you are "the smartest person in the room", not "the
smartest person in the room in one narrow area". If SMEs, PMs and Sales people
aren't smarter than you in some other areas, then you are somewhere with
incompetent SMEs, PMs and Sales people.

------
thegigaraptor
Peer Reviews (PR’s) are not a personal attack on your competency, but
constructive criticism and if they are genuinely toxic reviews, speak up and
point it out to another senior or manager.

------
Kmaschta
Write a LOT of unit tests, a good bunch of integration tests and enough end-
to-end tests. You'll be more confident in refactoring and with your developer
experience in general.

------
newusertoday
Blog about your work, things that you have learned etc. It will not only act
as your personal knowledge store it will also lead to unexpected
opportunities/connections.

------
isatty
I’m not a “senior” developer but what I try to improve on is always my people
skills not tech skills.

I’m not an algorithmic genius don’t get me wrong, that part doesn’t appeal as
much to me.

------
github-cat
Learn and act. Doing something real with what you learnt and you will grow
while you are building it. Also keep refreshing yourself with the new
technologies and trends.

------
intellix
Develop as a hobby on a project you can get passionate about and continuously
learn the stuff you don't know and look ahead to the future to get ahead of
the curve

------
gaustin
Communication skills are as important as programming skills. It is a super
power to be able to communicate clearly and appropriately for the
circumstance/audience.

------
dstjean
Make sure you don't stay in the same position for over 3-4 years. Make sure
you get promoted or look elsewhere.

IMO: Being too comfortable in the same position is not good enough

~~~
coj337
+1 I've seen lots of people work in the same position because they're afraid
they won't be able to cope with a new job. When they finally go elsewhere the
job assumes knowledge of stuff they just never learned that would've been
understandable a few years before.

Explore your options, never settle.

------
mediocrejoker
Don't be afraid to ask questions or admit that you don't know the answer to
something.

Asking questions like "How does this work" can be the fastest way to learn.

------
bdcravens
Learn the plumbing behind the abstractions/magic (say you're a Rails
developer, you'd learn what hashes are and how they work, how SQL works, etc)

------
grigjd3
Don't be afraid to ask questions and find the end of your knowledge quickly.
It's better to annoy an experienced developer than to accomplish nothing.

------
dmundhra
Have the mentality that what you are going to code will be used for at least 5
years, that helps in improving coding patterns, tests, corner cases, etc..

------
redleggedfrog
Polish your communication skills. Writing in particular. It will help you, and
help others, when you explain yourself or create documentation.

------
drcongo
In tech, there is no such thing as a stupid question.

------
franze
Read books!

~~~
yboris
I feel this advice would be better if it was more-focused. Trash fiction isn't
what the OP probably had in mind.

------
timwaagh
have an exit strategy. development is something people are passionate about in
a love it / hate it way. it's a hard job. that means you have to be able to
get out of it someday. sure you might be promoted, but that's not within your
control. so i saved, i bought a cheap to rent out most of it to roommates. in
a few years i wont be doing it for the money anymore.

------
martin-adams
My advice would be, if you can, find your calling (something that really
excites you) and then use that to learn as much to follow it.

------
frogperson
I always tell new developers to write the comments first. It forces them to
think thru the whole solution before jumping into code.

------
arminiusreturns
Tech doesn't exist in a vacuum, so do not ignore the board room politics!
Source: senior sysadmin who learned this the hard way

------
beat
Trying to make humans do the things computers do well is very difficult.

Trying to make computers do the things humans do well is nearly impossible.

------
alok-g
I had written this before [0] in a very different context but still relevant
to your question.

1\. Think Big. I have seen many people who aimed higher from the beginning and
did manage their way up (e.g., becoming a VP in just ten years, that too in a
large company).

2\. People skills is a must. You should be thinking of people or
organizational challenges all the time, or you'll miss the mindset to rise
significantly up.

3\. Many people complain about their team leads, managers or senior leaders.
This usually happens because these senior are working at a higher level of
responsibility and ambiguity than you are. You should rather be thinking what
would you have done if you were in their position. Understand the challenges
they have, by directly asking if needed. This will not only help develop your
relationship with them, but also position you to develop the skills needed
faster, without yet being in the position of responsibility that they are in!

4\. There is a lot of entropy in any team/organization, and unfortunately also
a lot of people who are increasing it. Be the one who reduces the risks and
brings order to the chaos, whose judgment can be trusted. Keep in mind for
this that the real challenges are often not on technology side (in other
words, if you think technology challenges are more critical, you are perhaps
missing the big picture).

5\. Try to become irreplaceable for the team/company in your project and
beyond. In my experience, this will not come in your way as [6] suggests. You
must however not get limited to the tools and technologies specific to the
company, or else your market value will suffer within a few years.

6\. Never say (or even feel) anything bad about anyone ever, keeping Hanlon's
razor in mind [1]. But then, how do you deal with the stupidity? Well,
<b>their stupidity is your opportunity</b>. (I created this out of Jeff Bezos'
famous quote, "Your margin is my opportunity." [4])

7\. Do not let yourself be masked from political issues around. A good manager
would aim to mask you [5], but that can curb your growth since you won't
develop the skills needed to master and survive corporate politics while being
masked.

8\. There are books available today that teach you corporate politics [2-3],
showing how easy it is for anyone to do it, and how difficult it is to
counter. Reading these books should be a required reading for anyone aiming to
go significantly high. And trust me, it's better to learn this from books or
from other people's experience than learning this stuff the hard way. (The
latter would be painful for one, and second, you may never actually learn.) I
have read [2] and felt that I should have read it earlier.

9\. Ask questions whenever you do not understand something or if your own
thoughts do not align with the decisions being made. Of course, be polite in
this (e.g., "I was wondering if option X also has been considered" instead of
"why are we not going for option X"). People around would be happy to explain
to you while also developing trust in you, and often would take the suggestion
if it will actually reduce their mental burden. The sooner the better in
asking questions.

[0]
[https://news.ycombinator.com/item?id=16490323](https://news.ycombinator.com/item?id=16490323)

[1]
[https://en.wikipedia.org/wiki/Hanlon%27s_razor](https://en.wikipedia.org/wiki/Hanlon%27s_razor)

[2]
[https://www.amazon.com/dp/0743262549/](https://www.amazon.com/dp/0743262549/)

[3]
[https://www.amazon.com/dp/0312332181/](https://www.amazon.com/dp/0312332181/)

[4] [https://www.inc.com/jessica-stillman/7-jeff-bezos-quotes-
tha...](https://www.inc.com/jessica-stillman/7-jeff-bezos-quotes-that-will-
make-you-rethink-success.html)

[5]
[https://news.ycombinator.com/item?id=16488447](https://news.ycombinator.com/item?id=16488447)

[6]
[https://news.ycombinator.com/item?id=16489904](https://news.ycombinator.com/item?id=16489904)

------
softwarefounder
Be humble.

------
brlewis
Look for two pieces of advice here that contradict each other. Find someone
who knows you well and ask which one applies to you.

------
vassilevsky
Become a PL polyglot ASAP. Polyglot perspective is so much wider that that of
a person who only knows one programming language.

------
Forge36
Run

In seriousness: get exercise. If you aren't in good shape it's draining, and
making your life harder. Coding is hard enough

------
therealmarv
Go to a company where they not distinguish a lot about this junior or senior
thing. Everybody can make a difference.

------
kraig911
Be aware of the latest trends but trust the oldest or most documented if it's
something super important.

------
partycoder
Some developers have n years of experience, others have the same year of
experience repeated n times.

The latter happens when a developer becomes too comfortable with their
knowledge and stops learning, or when they emphasize development speed over
learning.

If you want to be an expert, cargo cult needs to stop with you. Don't blindly
imitate what others do, try to understand how things work and how they can
work better.

------
rad_gruchalski
When you experience an error you have never seen before, copy the message,
paste in google.

------
ruffrey
Consistently be a great person to work with. Be a team player. Give feedback
with kindness.

------
melicerte
Cultivate another passion of you. Software development is just a job and
should remain so.

------
bulge_bracket
Dont be a junior software developer... You'll never get the responsibility you
want.

------
Deestan
When learning from mistakes either big or small, trace a few "why" back.

------
mkio
If you can't find a simple solution, you're thinking too complicated.

------
hd4
Never work unpaid overtime. Go the contract route early. Learn Python and SQL.

~~~
screaminghawk
> Learn Python and SQL

But not exclusively. Both are incredibly useful tools that will open a lot of
door for you, but I personally wouldn't want either of these to be considered
my bread and butter.

------
iamgopal
Next question : as an indie developer, what are my options for code review ?

~~~
baq
set your static analyzers to 'anal'.

------
supr_strudl
I've written something about becoming a better programmer here
[https://medium.com/@hadalin/how-to-become-a-better-
programme...](https://medium.com/@hadalin/how-to-become-a-better-
programmer-190084830aa4)

------
fietske
1\. Read Dijkstra's material: - learn about contract oriented programming,
pre- and post-conditions and invariants 2\. Learn about functional programming
and lambda calculus 3\. Read Joe Armstrong’s dissertation

------
bitwize
Get out. Save yourself, while you still can.

------
dave_sid
Read Clean Code by Robert Martin

------
virtualritz
Unless you already have a kick ass social life (hanging out with your mates in
a bar or at a soccer/football match doesn't count): learn
Argentine/Rioplatense Tango. It's the hardest couple dance and best suited for
engineers -- for many reasons. If ballet is the assembly language of dances,
tango is C. ;) AMA. :]

TLDR; I would give an eye or a hand if someone had given me this advice when I
was 20.

~~~
ValentineC
> _It 's the hardest couple dance and best suited for engineers -- for many
> reasons._

Please do elaborate!

------
bulge_bracket
Dont be a junior developer!

------
DeathRabbit
Be humble. You're not the smartest dev in the room. I was guilty of this in my
early career.

Related to this is realizing that most software degrades over time, being
touched by many people under varying deadlines. Assume best intentions of your
teammates until you _know_ there's a endemic problem.

Read code. Don't despair if you check out some cool OSS project and a lot of
it is going over your head: pick another project or start consuming the code
in small chunks.

Don't engage in bikeshedding.

Don't be an asshole.

Always be able to explain _why_ you: picked that solution, developed it that
way, favor X over Y, etc. Explain your thinking.

The "right choice" is typically right at the time the decision was made; time
will usually erode that "right choice" until it looks wrong.

If possible, document the reasons why critical/large decisions were made in
the project/codebase (e.g. "we had to do this like X since system Y wasn't
compatible with system Z at the time of writing").

Think of the next developer to touch your code. Think of you touching your
code 8 months from the time of writing. Both will help you documenting the
"whys" of your strategies if it may not be abundantly clear.

Follow coding conventions of everyone else at your company; don't try to buck
the standards.

Don't be cynical. Don't be a source of constant negativity. Those people suck
to work with.

Find programming forums/message boards and consume at least a few times a
week.

Don't obsess over picking the "absolute right solution", pick the one that
sucks the least given the information on-hand at the time. If it's a big
choice, document why you made that choice.

Do not burn out. If your company commonly features "death march" projects,
seriously consider leaving. I suffered a nervous breakdown around 5 years into
my career by working 60-80 hour weeks for months on end while dealing with
veiled threats about all our jobs. This was during an economic downturn and an
especially hard time to find dev jobs, but I still think it would have been
better in the long run to leave. I believe our company, knowing the tough
local market for devs, intentionally grossly overpromised on a deadline to a
huge customer because they knew many of us wouldn't have many options. I
probably made less than minimum wage that year, never did the math.

Related: in many cases, the company is not loyal to you at all. Do not devalue
yourself for loyalty to your company.

Always, always give credit where it's due. Never take credit for another's
work or ideas.

One of the best things you can do for teammates is relieving them of stress
and sharing the burdens; leave no one on your team behind (metaphorically).
This obviously depends on how close-knit your team is, but there were many
times I stayed late to help a close teammate with a production problem that
technically I wasn't directly involved with. When they did the same for me, I
was very thankful to have that other set of eyes, the person to discuss the
problems out loud. I know together we solved those problems quicker, to boot.

------
dmead
protect your hands. it's really bad if you lose some dexterity.

------
gokd3
Don’t use Sublime Text.

------
monksy
Always test your code.

~~~
mythrwy
Don't always test your code. Always test code that needs testing (i.e
production code) but never cargo cult.

It's just fine to bang out scripts or hobby projects you can see work easily
enough without formal tests. In the real world not everything is tested
(although probably more stuff should be than is).

------
jquast
read more code than you write. for your entire career.

------
natvert
Be nice. Work hard.

------
ratsimihah
Don't smoke

------
cristaloleg
Talk to people.

------
brightball
Learn to learn.

------
dmh2000
Take ownership

------
ratsimihah
Keep learning

------
drblast
Don't be afraid to ask for help. But don't ask for help until you've made an
honest ever to figure it out yourself. You learn best when someone isn't
spoon-feeding you the answers.

Your project will be cancelled and your team will be reorganized. The manager
you love to work for will leave.

The most important part of writing software is being able to understand it.
You should be able to understand it when you're writing it, debugging it, and
six months after you haven't touched it. Other people should be able to
understand it. That principal informs the following rules:

1\. Code for simplicity first. Do the simplest thing that can possibly work.
For whatever reason in this industry, people are seduced by cleverness and
complexity. You're doing a job, not trying to prove how smart you are. Clever
code that is hard to understand isn't smart. The problem you're working on is
probably simple. Don't try to make it fun and sexy when it isn't. Don't make
something harder than it is because it would be cool to use the new shiny ____
to write it.

2\. Don't repeat yourself. This is the opposite of simplicity, and your
problems compound the more you do it.

3\. If you have code that you are afraid to change for fear of breaking it,
you've failed to make it simple and understandable. All the testing in the
world won't help you if you don't understand the black box, and need to change
the black box.

4\. Code for readability. If you can't look at a line of code or an error
message and understand what's going on, you've failed to make it simple and
understandable enough. Functional code helps here; if you have to navigate
between 50 different files to understand what a function is doing, something
is wrong.

5\. YAGNI. You will never, ever, ever need the thing you're about to spend
time on and that dramatically increases the code complexity. If you _ever_ do,
it's much easier to refactor something simple than it is to work around
something complex that made the wrong assumptions. Build systems in small
steps.

6\. Use the compiler and type system. Everything should be as strongly typed
as possible to prevent future you from messing things up. The compiler is your
best friend; make it work for you and write code so that when you inevitably
have to change it, the type system prevents you from making a mistake.

7\. Get good at debugging. This is a skill that you develop that nobody
teaches you for whatever reason. When you're writing code while thinking about
how it will be easily debuggable later, you're doing it right.

8\. Use spaces instead of tabs. You'll make more money. Also turn on visible
whitespace in whatever editor you're using and delete those silly extra spaces
on the end of lines. I can see those and they're the code equivalent of
walking out of the restroom with toilet paper on your shoe.

------
eldavido
Kind of a hodgepodge:

Rack up experience. It's much better to be working than not working. It is
much better to have 2 years of experience and learning vs. 6-9 months looking
for something perfect -- this is especially the case for juniors. Just take
the first job you can get. Also, don't underestimate how much the rate of
learning differs between various workplaces.

Try to work somewhere that invests in people, especially juniors. Startups
will be "more fun", and you'll likely to get to work you're not really
"qualified" to do, but you won't learn how to do it well. One of my biggest
regrets is not finding effective mentors earlier in my career. Sometimes a
more "boring" workplace is better for this.

Most employers will judge your skills by the brands on your resume. This
mostly happens because there's no other reliable way of determining how good
someone is when hiring them, short of "I have personally worked with this
person before and can vouch for them" (the gold standard). A mediocre
developer who managed to clear Google's bar may be less of a good hire than
someone who worked diligently at a consulting company -- probably not in the
average case, but it's possible. Note this contradicts a lot with the last
piece of advice. It's a puzzle -- brand vs. skills.

Focus on your social network. Most good jobs, especially in more senior roles,
will be obtained through prior coworkers, investors, or other people you
know/have worked with. Keep up with people. Try not to piss people off. You'd
be surprised how useful it can be to leave a trail of goodwill behind you.

Understand that it is management's job to advance the shareholder's interests.
Most of the time this means they'll try to do what's right for employees. But
it also means that when the situation demands it, they will lie, withhold
information, fire people, report things to HR, and try to pay you as little as
possible -- that is their job. Filter every announcement and communication
through the lens of "how does this advance shareholder interests"? It's not
fair to say "everything management says is bullshit", but it's directionally
correct. Truth is not the priority.

Focus on developing skills that won't become obsolete. This means prioritizing
domain knowledge, CS fundamentals, etc. over the details of one language,
company, or programming environment. Try not to specialize in writing software
per se -- the market rate for this is rapidly heading to zero with outsourcing
and remote work. My friends who have the best careers (happiest, best-paid)
are people with very deep expertise (PhD + 10 years experience) in areas like
semiconductors, networking, or a particular business domain (e.g.
hospitality/travel, high-frequency trading) . The trick is not to specialize
too early -- wait to find something you really love.

Most startups aren't worth it. Some are. Many people have a binary view of
this: "startups good"/"startups bad". It depends on the people, the market,
and a lot of other factors. There are a relatively small number of investors
and founders who can reliably beat the averages. But not many. Informational
advantages in this area are worth _a lot_.

Silicon Valley is basically Hollywood. People move around a lot. Packs of
people who work together cross-recruit into new companies all the time. Try to
get into one of these "tribes". It will help you immensely for your entire
career. The PayPal mafia is a great example of what I'm talking about.

As you get more senior, do your homework and really stress out about which job
to take. It's worth it. This might be counter to what a lot of others say but
IT MATTERS. It's the difference between working your ass off for four years
and getting nothing, vs being able to afford a modest retirement after 4-6
years.

Plan to work 3-6 years in places, if not longer. It demonstrates commitment
and people in the upper echelons of business (investors, CEOs, high-level
management) respects that a lot.

If you work at a startup, don't always optimize for the biggest stock grant.
0.5% of a company that fails is worse than 0.25% of a huge success. Understand
that bad companies fail and good ones sell for tens of billions. Our intuition
wasn't built to handle 10 orders of magnitude differences in outcome.

I blog about a lot of this.
[http://davidralbrecht.com/](http://davidralbrecht.com/)

------
ratsimihah
Exercise

------
byteface
learn to touch type

------
ataturk
Learn how to "dig in." At least in the enterprise space, problem solving is
more important than the code you write. I have seen many people come and go
because although they can write Java, they can't figure out what to write.

------
Zhenhenry
Practice ..practice.. practice.

------
alias_neo
My advice would be; don't do it, unless it's a way of life.

Being a software developer is easy, I've seen loads of them, these are the
people who's work I end up fixing, it stresses me out and it costs the company
more because they've paid two people to do the job.

Being a good software developer is a way of life; if you're going home after
work and looking at ways to improve your life or other peoples lives by
writing software, you're doing it right.

Work with the best people you can find, the more experience these people have
than you, the better. Learn what you can, and make it your aim to be the best,
one day they'll come and ask you for help. This is the point where you thank
them.

Find something you're good at, find a niche language in your company or tool
set and become the go-to developer for it. As soon as you attain that, and
you're known as the go-to, find something else, work on the new thing, and
maintain the old, find languages you enjoy and master them.

Eventually, you get to a point where you're asked to fix/write code in a
language you've never used, and yet, with the API docs at hand, you don't even
skip a beat.

Also, remember this, no matter what you think, not everyone is far better than
you at this. There are some exceptional developers, but most are either
putting in a lot of hard work for the results you see, or they're average.

Finally; Never release on a Friday, and never make changes to production.

~~~
ck425
Disregard that first piece of advice. You'll hear a lot of bullshit about how
only people who love programming and want to spend all their free time
building things should be software engineers. Ignore them, ignore the imposter
syndrome and make sure you have a life outside of work - preferable doing
something that isn't just more programming. It'll make you a more rounded
individual and in the long run a better developer.

~~~
alias_neo
I'm not suggesting someone spend all of their time writing code outside of
work, I certainly don't, so please don't label what I'm saying as such, or as
"bullshit". Yes employers pull that crap, and want you to sell your soul,
that's not what I'm suggesting.

I don't think programming is something you become good at simply by doing your
9-5. I've worked with a lot of 9-5'ers and they're rarely the best or most
rewarded developers.

What I'm certainly NOT saying is that you should work _all_ hours, in fact I
will say exactly the opposite, don't, but, do be willing (if you're able) to
finish solving a problem before you call it a day. For your sake, not for your
employer's sake. I prefer to finish my work day on the last "problem solved".
It leaves you in a much better position to leave your work at work, than when
you have a problem you didn't solve and which will bug you until you solve it.
If you find a problem is going to take more than "minutes" to solve, accept
that its a problem for another day and try to leave it at that.

To further elaborate on my first statement, so it isn't misinterpreted again;

Do it because you enjoy it, and you _want_ to do more of it outside of work;
even if you don't do, but, even IF you don't, you can visit conferences,
meetups, hack-spaces, various other <insert-tech-or-language>-con, you'll meet
cool people, learn about things you didn't know and perhaps teach other
something. If you can make it "a way of life", contrary to ck425, do spend
_some_ of your free time working on programming tasks, find something
different from your work, for example, contribute some time to an OSS project
you like (for e.g. I use and like to contribute to Home Assistant) or some
other project you enjoy using, where you'll interact with the skilled people
behind those projects.

To be clear, that I'm not disagreeing with ck425, just that he (and probably
others) might misinterpret what I'm saying as "you should spend all your time
programming or else you'll suck": Do all of this, only after you done the
other things you enjoy doing more.

~~~
ck425
I still disagree with you. The idea that you should only become a software
engineer if you want to continue it outside of working hours is one of the
reasons our industry is primarily made up of white (or Asian) middle class
men. It's perfectly ok to do this as a job, a really good job, a career, but
still a just job that you don't pursue out of work. When we discourage people
who don't want to code in their spare time we discourage valuable alternative
view points and create a horrible homogenous industry (despite our industry
effecting just about everyone these days). Many people don't have either the
time, resources or inclination to pursue more coding out of work. And sure,
the techy who does loads of side projects will be a better coder, but there's
a hell of a lot more to this job than coding and it's perfectly possibly to be
a good engineer while only doing it 40 hours a week. We need to expel this
attitude so we can create a diverse workforce, which is proven to be more
efficient.

~~~
alias_neo
Well, when you put it like that. I can't disagree. I hadn't considered that it
puts off people that are not "like me".

I agree that we certainly need more diversity. I've been fortunate enough to
work in some reasonably diverse places and I'd hope to see more of it in our
industry.

To turn my argument around, I'll say that I'm a Software Engineer _because_ I
love it, I would be doing it anyway when I have the time, it's one of my
"hobbies" so to speak.

Given that I can't immediately think of a way to re-structure what I've said
in my previous comments, to meet this argument of yours, which I agree with,
I'll simply concede that I was wrong and leave it at that.

