
Ask HN: For those programming 10+ years, what do you wish you knew 4 years in? - dhruvkar
I&#x27;ve been programming for ~3 years now, first just on the side and now full-time. My learning has been in stops and starts. Now I can feel the cumulative learning paying off. I&#x27;m also realizing there&#x27;s SO much more to learn. What advice do you have for programmers just hitting their stride?
======
ravenstine
Everyone's code basically sucks, including yours. The boundary between a
beginner and a coding rockstar really isn't very great unless you are getting
into the realm of computer sciences, like machine learning. Learn from your
seemingly smarter peers, but don't idolize them. Chances are they will leave
the company long before you do, and you will figure out that their coding
skills aren't all they are cracked up to be, especially if their code is
poorly documented. You will soon understand that they were focusing on getting
the job done, while you were expending all that effort to be clever. In that
sense, they were totally right.

Don't overwork. Seems obvious, though it's not only still prevalent in
America, but more important for our field. Working extra hours has rarely
benefitted me either in quality of work or in company treatment. Nobody cares
that you put in extra hours. In fact, don't expect your boss to care about
anything you are doing even if they are generally benevolent.

Your success is mostly dependent on your personality with appearance as a
close second. That's not to say you won't have big wins with the projects you
work on, but a lousy programmer won't get fired if they are charming and
everyone likes them. The more I refined my social skills, as well as my
grooming, the more my minor achievements would get overinflated by my peers
and the more they would overlook my mistakes. It's just a cruel fact of life,
but at least it's something most people can actually address.

~~~
tekstar
> The boundary between a beginner and a coding rockstar really isn't very
> great unless you are getting into the realm of computer sciences, like
> machine learning.

This is really untrue. On the surface, code might look the same between a
beginner and a senior developer, but the decisions underlying the code will be
night and day. Beginners will solve the problem of the day directly, with no
care for introducing complexity and no willingness to reconsider past
decisions.

~~~
cookiecaper
My interpretation is that most of this disagreement is just from ambiguity
left by the parent's brevity.

Experience certainly shines bright in architectural and design decisions.

I think the parent's point is that no one's code should be considered
sacrosanct; all of us can make mistakes, and all of us, even the senior guys,
will end up writing some ugly hacks just to get something out the door on
time.

More junior programmers should not be afraid to make a pass at improving
something, nor should they try to emulate their peers' styles or behaviors
without thinking about and processing them, lest they internalize bad habits.
If a junior dev notices an error, they should point it out, instead of
assuming the senior developer's code is beyond reproach. They should
understand that once they get added to the resident Wizard's project, they're
still going to have to deal with the reality of a production application,
which means shortcuts, impurities, bugs, and mistakes. The principle of
Linus's Law depends on developers who are willing to call out mistakes and at
least prompt a discussion about the tradeoffs.

This doesn't mean that senior developers won't be _much_ better at writing
maintainable code on a macro level. This is especially true because I've found
it usually takes until upper-mid-level for developers to really get an
appreciation for simplicity and avoidance of technical debt, and to register
that you're actually _better_ if you can do more with less. (n.b.: speeding up
a computer program is just making it do less)

~~~
lsiebert
That's why comments should mostly indicate the why of a design/architecture
choice that was made, not what the code is doing.

------
scarface74
I have been developing professionally for 20 years and I'm in my early 40s.
What I've learned:

* Salary compression is real: most companies are not going to keep giving you raises to match what the market would give you for your skills. They would rather you leave and take all of the institutional knowledge with you than pay you the amount you could get elsewhere. Even if that means hiring someone else at market value.

* Don't get comfortable at a company to the point you're not getting new experiences and learning new skills. Don't become a dinosaur.

* Even if you don't want to become a manager, when the time is right and you have the right skill set, demand a title with "architect" or equivalent in it. Titles are B.S. but people listen to developers with "architect" as part of their title. I insisted on the title and now I'm being recruited for much higher salaries even though I had the same responsibilities as a "senior".

* Good local recruiters are your friends. They can tell you salary ranges for a job and they do a lot of the hard work for you.

* know how to calculate your contract rate if you're doing contract work. Your rate will be different if you are a W2 contractor vs a 1099 contractor. Take into account self employment taxes (1099), the lack of PTO, the time between contracts etc.

* Whether you are a contract or perm, realize that you are still your own company. Your employer is your customer. Do you your best work but never feel a sense of loyalty that keeps you from jumping ship for higher pay. They don't have any loyalty to you.

~~~
lackbeard
> Titles are B.S. but people listen to developers with "architect" as part of
> their title.

I would be careful with this advice. It might get you a cushy job and a higher
salary at bad companies, but I think it's bad for your career in the long run.

In my experience most "architects" don't do any real work while cooking up a
bunch of "best-practices" that sound good in a vacuum but either fail
completely or create a big unnecessary mess when it comes to actual
implementation.

In my experience, real practitioners who are actually worth paying attention
to usually have the title "Lead", "Manager", "Director", or "Principal".

~~~
scarface74
I was recently told by manager - who insisted on his title as "director" not
managsr - that the title "manager" is actually seen as more tactical and not
strategic and has less respect.

I would rather be called a "lead" than "principal". A "principal" is seen as
an individual contributor, an "architect" is also usually an individual
contributor but could also be someone who interacts with various departments
to get stuff done.

------
rhubarbcustard
That shipping stable software that works and meets requirements is what people
really want. In other words, what the non-tech business people want, or your
customers want, is software that fixes their problems, makes their lives
easier or makes them more money.

It's easy for us programmers to become fixated on using a newer JS framework,
a slightly tighter Java loop or the latest cool language. Took me a few years
to realise that even though I care a lot about those things, other people do
not. They are interested in the outcomes, not how it got built.

I'm running my own business and building things for myself these days. I use
vannilla JS on the front-end and Java 8 on the back. Since I gave up chasing
the new cool tech I have built a bunch of stable systems that have been great,
well received, products.

If you become someone who has a history of shipping things that work, you will
do a lot better than someone who knows how to write hello world in every JS
framework.

~~~
Tinned_Tuna
This. Make your _business_ case, not a technical case. This applies to
software engineering, security engineering, etc.

The above comment does not absolve you from doing cool things, it's just that
the cool things should align with business interests. No yak shaving.
Sometimes writing a one-off script will take 30 minutes, and doing it by hand
will take 10. Do it by hand.

~~~
i336_
Here's my problem.

I'm not particularly prolific, so the number of ideas I have far outweighs my
execution so far. This is mostly due to ADHD and other issues which I'm
working on fixing, and while contextually relevant is not my point.

This lack of prolific-ness means that I have a literal _tower_ (it's rather
intimidating) of wanting to build cute but objectively not so useful routines
simply for the sake of building them.

I realize this is essentially the foundation of creativity, but I have a hard
time justifying doing these things as I take a very long time to execute
_anything_.

So, the ideas file themselves away - and surface when I'm trying to design
actual things I'd like to build. And I get horribly distracted with doing X or
Y a certain way, or I get carried away with _how_ I can build Z out like this
or that idea I had two years ago...

My problem is focus, I think, and mental partitioning, which I'm not good at.
Does anyone have any suggestions for how I can do that?

~~~
qaid
Your "problem" sounds different the one I currently deal with.

My current solution is to have a backlog and spending time to prioritize them.
I'd focus on my top priority, and continue writing down new ideas as they come
into my mind. When I finish with the top priority, I re-evaluate to find out
where the recent ideas fit in. I'd also look into reading about the agile
methodology.

If you're like me, ideas come in very frequently. Embrace your creativity and
ambitions by logging them. But try and shift your mindset to thinking about
what is actually necessary for the final product.

~~~
gm-conspiracy
Also, "freeze" your "features" at versioned levels for each project.

If you want to add or alter something, that would be a new project.

Otherwise, you will never finish a project.

~~~
antoniuschan99
eg. "Sprints" in Agile

------
maxxxxx
Work somewhere where software is the main product and not just a cost center.
You can learn a lot quickly if you do cutting edge things with people who care
about technology and not just cost.

Solve real world​ problems. Doing elegant things is very difficult because the
real world is much more convoluted than theory.

Do a few things in depth. Don't jump at the latest thing every few months.

~~~
randcraw
> Work somewhere where software is the main product and not just a cost
> center.

This is THE big difference between S/W dev and IT. For 20 years I worked in
the former, and for the past 10 in the latter. No question about it: IT is
hell. Theirs is a never-ending mission to reduce the cost of moving data and
being "compliant" with often-meaningless ever-excessive corporate standards
(and _forever_ meaningless MBA/CIO fads and groupthink).

Worst, in most businesses, IT doesn't have a respected mission. Ii provides an
infrastructural service (a cost center) that other C-suiters dis as no more
important than HVAC and sewer. IT appears on their radar in only two ways: 1)
when something breaks and info clogs up or stops moving, and 2) when the
budget is revisited and interest in IT cuts are reinvigorated.

Since nobody else in the corp. respects IT's mission, senior mgt. compels the
CIO to adopt meaningless surrogate goals because IT's actual mission isn't
sexy enough. So for the next six months IT adopts "Platforms" or trains half
the staff in Six Sigma, or outsources, or insources, or promotes of whatever
other CIO groupthink initiative is in vogue at the moment.

So yes, work somewhere software is valued, unlike IT.

~~~
QuantumGravy
Having regrettably started from the IT side, it's seemingly impossible to make
the jump to a software company proper. Nothing I do day-to-day is flexing any
mental muscles an interviewer would find sexy. We're like a permanent
underclass of undesirables. Without spending time outside work to focus on
sharpening basic undergraduate CS knowledge, I know I'm getting objectively
rusty at the types of problems I actually do have some remaining passion for.

I fear I'll be hammering out poorly-spec'd features to the beat of another
department's Gantt-chart for the rest of my life.

~~~
bpyne
I sympathize. Early in my career I landed a job in a small software company.
My skills improved greatly. Then I made the mistake of taking an IT job. That
IT job rolled into another and another. While I stay near the technical top in
my IT departments, I find it tough interviewing for software company jobs. The
concerns of a software engineer in a software company are just so different
from an IT developer’s.

I interview for backend engineer jobs. I notice a common theme in the
interviews: efficiency. They are very concerned with transactional throughput.
They optimize everything from the services layer to the database for trimming
every microsecond. At a past interview, the people wanted me to talk about the
efficiency and implementation of various data structures: nothing exotic, just
garden variety queues, stacks, lists, and hashmaps. They quizzed me on
threading issues. One guy got into various indexes in a relational database
and then jumped into TCP vs. UDP questions. In my most recent interview, the
guy started by asking me the difference between optimistic and pessimistic
locking. In my IT job, I never deal with locking issues: they are all
abstracted away. Two-thirds of the way through the interview, I remembered and
circled back to the question. However, the damage was more than likely done. A
person who deals with those issues daily would never forget. But, I know what
to work on for the next interview.

I understand your predicament. It’s deadening on every level when you’re doing
work beneath your capability and interest, but you don’t have the necessary
knowledge to get through an interview for more interesting jobs. Hopefully,
the observation I made above helps you to target particular areas to
successfully navigate an interview.

~~~
cookiecaper
Find a place that will quiz you on real-world work instead of CS textbooks.
There are a lot of them.

Companies who base their interviews on CS curricula generally just end up only
hiring people who've graduated recently enough to remember it (i.e., their
staff ends up being junior because they're selecting for something that's,
ironically, an anti-indicator of experience more often than not).

------
bitL
There is no future in software development as a job. Move to a management
position quickly, network, make friends with decision makers, don't spend too
much time on crafting your skills, your reward for perfection will be more
insane work and crazy interviews where one part not 100% done kicks you out.
Work on your appearance, kiss up, lift, dress properly, use anti-aging
cosmetics, make cool looking hairstyle, wear objects of power (like rings),
work on your voice, make yourself seen by making presentations, even if
pointless and/or stupid, do some trendy thing on a side and show everyone,
appear confident at all times even if you have no clue what is going on.
Demonstrate your skills by getting an MBA, PhD (even if from a crappy
university, it doesn't matter) or a respected certificate. Basically, don't
hack computers but people around you. Our field has shifted from meritocracy
to over-politicized field, if you are a male you'd in addition face 50/50
gender ratio split pressure and given how few women are in our field, you'd
compete for less than a half the available spots as everyone now wants to
compensate this ratio in their mostly male teams.

If you really need to make software (like I do), make your own company and
license/sell your work instead for >500% more than what would be your salary.

~~~
kzisme
> If you really need to make software (like I do), make your own company and
> license/sell your work instead for >500% more than what would be your
> salary.

The hardest part about this (for me) is finding a project/product to begin
working on.

I'm assuming you came to that sort of idea while working for others (which
seems like the best way to learn).

~~~
efm
If you do all the other recommended things, you'll start hanging out with
people who spend money to solve real business problems. The projects will come
to you then.

~~~
kzisme
Would you say this is true even if you're not living in a tech hub like SF?

~~~
efm
Yes. You'll meet different kinds of business owners, but they will have real
problems.

~~~
kzisme
I see - would you also agree that you will meet other people (such as other
programmers/designers/etc) over time? I haven't met more than five at my
current job.

------
falcolas
You're going to read your code 100x more than you're going to write it.
Optimize the code you write for reading.

Your code will be in production either much longer or much shorter than you
think it will. The 5 lines of code you spend three days perfecting will be
replaced in a week, and that one-line 3am hack will be out there for ten
years.

A good walk around the block will help you solve a problem faster than staring
at code.

Find someone smarter than you and learn from them. The corollary is if you're
the smartest person in your area, you're more likely to stop learning.

What the customer needs is rarely what they say they want.

You will derive more long-term benefit from finding an answer yourself than
finding that answer on Stack Overflow, at the cost of time. When time matters,
at least try and understand why the Stack Overflow answer is right.

Don't be afraid to question a decision you don't understand, or don't like. At
best, you'll get either your mind or the decision changed. At worst, you will
learn something about your co-workers.

There's never enough money, time, or domain specific knowledge.

Office politics matter, regardless of how much you wish they didn't.

~~~
e12e
> Find someone smarter than you and learn from them. The corollary is if
> you're the smartest person in your area, you're more likely to stop
> learning.

Maybe. I think the other side is find someone smarter than you, but _less
experienced_ , and teach them.

You learn much more from teaching than being taught.

If you're at loss of finding smart adults, find some children ; they're
probably all smarter than you, in the sense of finding good questions (which
is much more interesting than finding good answers; finding answers is just
work, finding great questions require inspiration. A perfectly good example of
a good question is: "why is the sky blue?").

~~~
falcolas
If you can't find someone to teach you, then yeah, this would be a good
alternative. And so long as you're willing to put significant effort into
correctly answering their questions, it should be a good substitute.

That said, teaching will not typically help you learn something new, though it
will help refine the knowledge you already have.

For example, answering "Why is the sky blue" will give the chance to refine
your own understanding of refraction and how that interacts with air, but it's
unlikely to guide you into learning about quantum mechanics.

~~~
vikiomega9
> unlikely to guide you into learning about quantum mechanics

True, but that depends on assuming the person teaching is really only
interested/aware of an answer that deals with refraction, and that the median
mental model most people have isn't close to understanding the mechanics of
refraction. I've noticed that the levels of abstractions we employ are all
affected by these sorts of questions, perhaps the same question a year later
would afford one the chance to unravel a particular layer assuming the layers
above it are sufficiently saturated in understanding :D

------
ZoFreX
If I could go back in time and give myself advice it would be:

0) Nothing is too hard to do, no matter how much those doing it might seem
like towering titans many levels above you, or how out of your reach it may
seem. Nothing is too hard, there are only things that take time, and things
that take more time. If you put in the work, those titans will be your peers
before you realise it. Of course, you can't do everything. If you want to put
in the amount of work needed for some things, you need to focus. That means
deciding to not do some things that you want to do.

1) No-one who is serious about programming gives a shit about language wars,
they're for fanboys and spectators. People who get shit done are too busy to
spend time on that. So don't sweat what language you choose (too much – there
is still such a thing as the right/wrong tool for the job) and especially
don't worry about the people insulting it.

2) If it's not constructive practice, you're wasting your time. I spent too
much time - literally years - spinning my wheels, writing code but not getting
any better at it. Make sure you're reflecting, make sure you're improving.

3) (related to #1) seriously stop worrying about choices and just get
something done. You don't get things completed by worrying if you're using the
right language/framework/library.

Unfortunately I worry that this advice would send me down another bad path and
I'd probably need to add on something like:

4) All that said, some languages really are limiting, either in what you can
do, the level of concepts you will learn, or straight up teaching you bad
habits. Likewise some libraries / tools / frameworks are actually bad. While
you should definitely avoid trying to optimise the last % of productivity, you
should spend some time to make sure you're not using something highly
suboptimal. If after reflection you believe you are using such a
language/framework/etc, then broaden your horizons. That doesn't necessarily
mean rewriting your current project, maybe do a toy project or some exercises
in something else.

~~~
dingo_bat
Regarding 2, how do you suggest I avoid "spinning my wheels and learning
nothing"? Over the last 6 months I've becoming increasingly aware of this
problem with me, but I don't know how to fix it.

~~~
klibertp
Whenever you set out to write something, write it differently than last time
you did it. It takes conscious effort and a lot of getting used to but
actually stopping and thinking about alternative ways of doing something is a
practice in itself. When you act on these thoughts, you're most definitely
practicing, and quite probably improving.

This approach scales from the tiniest pieces of code to whole systems. If your
last loop was a simple `for` loop, try writing the next one as a call to map
function. If your last loop was implemented as map, write a simple `while` the
next time. If your last app used Postgres for persistence, use Redis or
CouchDB for your next one. If you're comfortable with MVC, use MVVM for your
next project. If you're fine with dynamic typing, try using statically typed
language or dialect.

Seriously - do it. Nobody is going to say anything to you: they all do the
same to stay relevant, even if they know it's _not_ the best strategy for a
team as a whole. Make it your policy not to repeat yourself and only fall back
to the tried-and-true ways of doing things if there are external circumstances
which put you under some great pressure.

After a couple of years of this, you'll accumulate most of the techniques and
skills you could ever need. The techniques and skills I talk about are
transferrable between tech stacks to a certain degree, are impossible to
learn/master quickly (no matter how intelligent you are the amount of
information is simply too great) and really matter in practice. That knowledge
is what differentiates senior programmers from others.

Anyway, good luck!

~~~
jrumbut
I don't know about doing this in a project you're being paid for, it certainly
increases the cognitive load of reading a codebase where simple things are
done differently all over the place.

Four years in I'm hoping the OP has seen a pretty broad range of different
styles and approaches and is now ready to hone their craft with smaller
improvements, and is no longer struggling just to get something working so
they now have some extra energy to put towards maintainability and overall
system design.

It might be better to try to define and refine a consistent style that can be
applied to an entire project, that way you have to evaluate all the options,
and do everything intentionally, but also you're not sending the next dev back
to the syntax manual every time they try to read a new function.

~~~
klibertp
> it certainly increases the cognitive load of reading a codebase where simple
> things are done differently all over the place.

But simple things are being done differently anyway, all the time. There's too
much variation in how you can code anything. The most trivial functions, like
leftPad, can have dozens of implementations across a couple of projects - each
as correct as the others, some abstracted, some inlined. Above a certain
proficiency level, programmers are expected to intelligently recognize leftPad
when they see it, even if it's called `frobnicate` and is implemented
backwards (whatever that would look like). How can you expect programmers to
do this without them going through a large set of sample implementations? Are
they going to wake up some day to realize they got enlightened and now have no
problems with dealing with leftPad in any of its many forms?

I find the argument of "increased cognitive load" entirely unconvincing. Yes,
the code should be optimized for reading. But, as every writer knows, how you
write depends on who are you addressing. In other words, it's both insulting
and counterproductive to write your code as if your readers are bird-brains
with severely damaged hippocampus. Your readers are professional programmers
who know their craft - possibly better than you do - so have a little faith in
them!

------
KirinDave
5 things:

1\. That statistics and metrics collection is incredibly important even if you
only ever use it via libraries.

2\. That code performance doesn't matter if the code is incorrect or insecure.
So much of my life in industry has been tainted with an influence to conform
to the cultural norm of "fast is best." This influence and culture is one of
the most counterproductive parts of our industry.

3\. The industry is actually full of great people, but those people avoid most
of the media hubs that projects have access to because a tiny slice of
terrible people dominate discourse. These assholes set the tone for the entire
industry, and should be ostracized and punished. It's not everyone, it's a
thin coating of hate.

4\. Corollary to 2 and 3, I wish I learned to ask for help earlier in my
career. I wish I could go back to my younger self and take the chip I'd
acquired working with government contractors.

5\. Corollary to 4, I wish I realized that I should be reading academic papers
and that the people writing them weren't wasting time. Much of what's
considered modern state of the art is in fact 5-10 year old work out of
universities and MSR.

------
ransom1538
13 years.

0) Money. the big money is in projects that need help. E.g. CEO during your
interview: "The last lead programmer flipped me off and our accounting system
in small talk is broken." That's hard. But that is where money is.

2) errors happen. Do tdd - so you can go to that concert.

2) Be the go to guy. If someone needs something you better be able to help.
Brushing someone off creates office enemies and will remove any hopes of
promotion.

3) any idiot can write code. I can with one hand tell you the names of people
that can take over a system with 500k of mangled code.

4) think win/win. If you are doing a project - work hard -win for the company,
but also put it docker so you learn something too.

5) launch side projects. You should release something large every year.

~~~
jrumbut
I really like this response because it is helpful and practical but not
overwhelmingly cynical or Machiavellian. You can do well by doing right in
this field!

I think a corollary to 0 is that if an organization is in trouble it will
usually find a way to always be in trouble. It's human nature to think a
crisis is always almost over, often it's only beginning.

For sure, taking over a troubled project is a great and honest way to make
money, and I love sorting out tangled messes where the original developers
have all left (hit me up if you've got one, email in profile!), but just make
sure that the problem wasn't a chaotic or toxic work environment.

People and their interactions are more important than events and circumstances
in terms of creating an environment. Some teams run on crisis and others run
on collegiality. The direct and indirect benefits of a positive work
environment are tremendous.

------
root_axis
If you're self taught, get a degree as soon as you can, even if you take night
classes over an extended period. No matter how good you are, a large portion
of companies and recruiters will autotrash your resume without an education
section.

If you're not a founder, NEVER take equity in leu of salary. If they offer a
competitive salary _and_ equity, that's a significant plus, but equity as a
portion of your compensation value is essentially a scam. if the company goes
under or you're let go before the cliff (which is usually two years or more, a
lifetime in this industry), all that money disappears: not true of salary. If
a founder or officer alludes to houses, cars or other riches as a pitch to
join their company _run_. Seriously.

Take the time to understand systems and infrastructure. Not every dev needs to
be a kubernetes expert, but the big difference between a code monkey and a
code assassin is that the assassin can deploy their own code to production if
necessary. If you're a web dev and you can't configure nginx or apache, you
have a gaping hole in your skillset.

Launching off the last point: learn to be competent with linux. Linux is the
preeminent environment of the software world and it pays huge career dividends
to be able to script, configure, compile, install and maintain linux software
and systems.

RTFM. This is a big one. Don't skim. Relax and dedicate some time to a
thorough understanding of details. You can save yourself an immense amount of
time when working with a new library/framework/language if you actually read
the manuals and understand what your tools are capable of, otherwise, you end
up wasting tons of time brute forcing your way into a crude solution that may
have been trivially and correctly solved by utilizing the tool's strengths and
features where appropriate.

~~~
umurkontaci
> If you're self taught, get a degree as soon as you can, even if you take
> night classes over an extended period. No matter how good you are, a large
> portion of companies and recruiters will autotrash your resume without an
> education section.

Not true. I'm self taught and I had very generous offers from the two of the
three big names.

Screw spending a time to getting a degree just for the sake of it and build
stuff.

I know it wasn't like that before, but times have changed and so have
recruiters.

~~~
root_axis
I don't mean to suggest that you can't get great opportunities while self-
taught, only that a sizable portion of opportunities will be closed off
without a degree. There happens to be a glut of developer work at this time,
so the consequences are dampened, but that won't be the case forever, better
to get the degree when you don't need it rather than wait till the time when
it makes a bigger difference. Also, I'll add that getting hired by an elite
software firm is absolutely possible without a degree, but you have to be
considerably above average intelligence and skill to get in the door, whereas
a degree will give you an opportunity to get in the door even if you're not a
star, providing you with the environment and resources to become one.

------
avaer
\- Keep it simple, stupid. Advanced is not a compliment.

\- Languages and frameworks don't matter. There's a closed set of concepts
they're all reusing. Especially if it's hot shit: that means someone mined
ideas from 30 years ago.

\- Most problems tend to fall not to cleverness, but to compute power and the
right glue. See previous two points.

\- Everything is a tradeoff, everything is a moving target. Programming is
about the battles you choose.

~~~
scriptkiddy
I like this. No bullshit. Straight to the point. Solid advice.

------
patio11
~13 years in:

Spend your early career, to the maximum extent possible, in well-run
organizations surrounded by supportive, skilled teams, so that you can
optimize for skill growth and (secondarily at first, but growing over time)
for individually attributable impact/ownership.

Honorable mention: AppAmaGooBookSoft hire mere mortals, too, and mid-career
salary expectations at them are $300k.

~~~
annnnd
> AppAmaGooBookSoft

Interesting... I have always steered clear of such jobs because I felt I would
be just a cog in the machine. It seems to me only a select few in those
organizations ever shine (and most of them achieved their status before
joining AppAmaGooBookSoft). Am I mistaken?

~~~
patio11
I know a variety of folks there, and their experiences range from "cog in
machine" to "really couldn't imagine working anywhere else", and there are a
lot of machines you can be cogs in that don't pay $300k (ask the former
Japanese salaryman).

The _main_ reason I mention it is so that everyone knows to aim for a package
(compensation, skills growth, interestingness of work, life happiness,
whatever) which compares to a clearly achievable outcome which tens of
thousands of people of similar skill levels get offered every year.

~~~
vonmoltke
> which compares to a clearly achievable outcome which tens of thousands of
> people of similar skill levels get offered every year

Are you asserting that those five turn over a majority of their mid-career
engineers annually? That's the only way I see the tens of thousands number
being accurate.

As for "mere mortals", I think most of us realize these companies hire them.
Hell, I've been interviewing for my company a lot recently and a number of the
people from those companies have been underwhelming at best (some to the point
of causing me to wonder how they got hired there and I didn't). The issue is
that many of us have soured on the random bullshit in their processes and have
decided to stop throwing ourselves at it. I think it is a disservice to the
up-and-coming not to acknowledge that and for them to realize it is
"realistic" in a similar way that hitting a number in roulette is.

~~~
patio11
_That 's the only way I see the tens of thousands number being accurate._

What's your over/under for how many engineers AppAmaGooBookSoft will hire this
year? Mine is 50k. I did a back of the envelope calculation for this last year
but can't find it.

90% retention rates imply a 5 year survivorship of ~60%; feel free to take any
of several thousand HNers out to coffee if you want to confirm what competent,
worksmanlike execution means your 6th year pay package looks like.

~~~
vonmoltke
The five combined have a _total_ headcount of roughly 660k, meaning they would
need to be hiring annually roughly 7.5% of their total just in software
engineers. At that level I don't buy it.

Since the number is dominated by Amazon, who has a huge logistics contingent,
I'm not sure specifically about engineers. I'd say roughly half of that total
is engineers that have something to do with software (not necessarily software
engineers). That bumps your number to over 15% of the total engineering
headcount. I'll be conservative and say 25% of the engineers are not software
(with most being in Apple and Amazon). Now we're looking at 50k being 19% of
the total software engineers.

You seem to be talking about hired at all levels, while I was talking about
only senior hires. In that case, I am closer to you than I indicated. My
(possibly wrong) impression is that the majority of hiring by these companies
is new grads and juniors, since that is what their interview processes are
heavily biased towards. I put the total number of senior hires at 10k - 15k.

As for total hires overall, I'll buy either your total hires or your retention
rate, but not both. These companies are not growing headcount fast enough to
be doing that much hiring at that retention rate in software engineers alone.

~~~
JoachimSchipper
Median tenure at Google is about a year:
[http://www.slate.com/blogs/business_insider/2013/07/28/turno...](http://www.slate.com/blogs/business_insider/2013/07/28/turnover_rates_by_company_how_amazon_google_and_others_stack_up.html).
Amazon is famous for burning out _some_ of its employees very quickly. Why do
you think 7.5% is a reasonable number?

~~~
vonmoltke
You seem to be agreeing with me, so I'm not sure if I understand you...

I was addressing Patrick's numbers (50k software engineers per year and >90%
retention rate). Your link provides evidence that the latter number is
incorrect, which was part of my point in both posts. In fact, it demonstrates
that Patrick's 5-year scenario is the exception rather than the rule.

~~~
JoachimSchipper
I'm sorry, I just misread your post - I am, in fact, agreeing with you.

(Of course, both you and Patrick can be right if the typical 5-year trajectory
involves only well-paying jobs, even it's usually more than one job.)

------
runeks
Haskell.

I spent at least five years chasing down "AttributeError: X has no attribute
'Blah'"-errors in Python at runtime, and came to think that this was what
programming was. Three-or-so years ago I discovered Haskell, which transforms
these types of errors into compile-time errors, preventing me from building
the program as opposed to a sudden runtime crash.

I wonder just how many hours I've wasted doing this completely meaningless
task. It's not really a problem while your programs stay small but, as they
grow, I found it became the main source of time spent programming, taking away
precious time defining the actual application logic.

Mind you, Haskell is fairly extreme in this regard, and I'm sure there are
languages which take a similar approach, without the mathematical certainty of
Haskell. But, as I've become used to the precision offered by Haskell,
settling for something with fewer guarantees -- but more libraries and easier-
to-digest documentation -- would feel like a great loss to me.

~~~
Scea91
Your comment is not about Haskell but about static typing. I agree with you
but there is no need to learn Haskell to enjoy static typing.

------
baccredited
I wish I knew I could save aggressively and achieve financial independence in
a relatively short time frame. Even medium salary programmers in the US can
save the bulk of their income and retire early (if they so choose). I'm on
track to retire in about 4 yrs but wish I had done so quicker.

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

~~~
rhexs
By retire early, do you mean retire like Mr. Money Mustache suggests, -- i.e.,
extremely low cost of living, don't use AC, don't drive anywhere, probably
live on less than 20K a year?

Or are you making a large enough salary in the PNW/San Jose or something where
you can put back 1-3 mil in 10 years?

I ran that calculator and while it says I can retire soon, I've always heard
25x income to be a much more reliable number.

~~~
baccredited
No I'm not a lean FIRE guy like MMM more of a FatFIRE
[https://www.reddit.com/r/fatFIRE/](https://www.reddit.com/r/fatFIRE/) Our
family spends like a drunken sailor on shore leave. I'm lucky to come from a
dual income family and save 100% of my salary. I'm targeting saving 25x yearly
spending.

~~~
rhexs
Thanks -- haven't heard that term before. I'll check it out. I like the idea
of early FI but I'd like more a cushion that I think some of the lean guys are
going for.

------
crdoconnor
* Develop a good eye for hype and real trends. Try to follow the real trends and avoid the hype-fests. Avoid investing time learning fly-by-night technologies, but when something new and genuinely better comes along, jump on it.

* Listen to developers who have deep and abiding hatred for some technology that they can argue coherently (with a range of deep technical details, links to bug trackers, etc.). These rants are a gold mine can save you a universe of pain.

* Almost all good coding boils down to three things - choosing a less powerful language/approach, writing less code to do the same thing and looser coupling.

* All things being equal, take the job with the higher pay. It almost always means you're treated better in other ways, you work with better people, you work with better tech and on better code.

~~~
kavehmz
You nailed it! Perfect.

------
krylon
I was kind of shocked at the discrepancy between the reality of working as a
programmer at a small company and what one learns about how to "do things
right the right way" \- version control system? What is that? Automated
testing? Or even systematic testing? No time, we have to ship the next
release! Using global variables sparingly? - _Hysterical laughter_

The important lesson for me was not to despair and not to get all preachy on
the other programmers, but to see how to make the best of that situation. And
while it was a real pain at times, I was able to be productive and get some
real work done.

Also, if the only tool you have is a hammer, every problem starts to look like
a sore thumb eventually. Do not stop learning new things. Both for pragmatic
reasons, and because it helps keeping it fun. It doesn't mean one should use
every shiny new thing out there just because. But without knowing what options
you have, making the right choice is not trivial.

~~~
skybrian
Do you use source control just for yourself? How do you keep sane?

~~~
tobyhinloopen
When coding on my own, I use: \- TDD \- Version control systems (GIT) \-
Issues to describe new features & bugs \- git branches \- Pull requests with
code reviews (I create something based on an issue I created and review the
code later, pref. a day or 2 later)

It seems tedious and slow at first, but it really isn't in the long run. It
results in clean, organised flow of code & projects.

------
yonah
I've been coding professionally for 20 years, a lot of the comments below are
legit, but I figured I'd add one or two more:

\- As many people point out, the languages don't matter - something better and
newer will come along, and you'll need to adapt, but that's not where
programmers provide value - they provide value in understanding how to solve
the problems that the business side is facing. It's easy to find someone who
codes better than you - new grads, offshore devs, but it's harder to find
someone who understands your business well and can solve the problems that
it's facing.

\- Always be learning, always be reading, always be innovating.

\- If you can, contribute to Open Source and/or stack overflow, etc. People
who interview you will do their homework, and you want to have a public
presence that will help sell you.

\- To me, the most important thing, is to try to work for an organization
where you are the dumbest person in the room. It might sound counter
intuitive, but if you are the smartest person there, who are you going to grow
from? At the very least, when you look for a job, the people should matter the
most. Obviously, pay, technology, commute, etc. all matter, but if you
surround yourself with a good group of people, it makes work easier. The jobs
where I was by far the most skilled and the most talented wound up being the
jobs where the less-qualified people on my team became the biggest drain on my
attitude and time.

\- If you are going to go the management route - make sure that you get
training. Can't emphasize this enough. Just because someone is a good
engineer, and is able to self-manage and prioritize well, doesn't mean that he
or she is good at managing other people. Just like you didn't learn to code
overnight, you won't be able to learn to manage overnight. (That advice alone
15 years ago could have put me in a different trajectory).

~~~
kidproquo
I completely agree on every point here. BTW, what training would you recommend
for the management route?

~~~
efm
Join a nonprofit in a board level role. The local chamber of commerce has
leadership training.

Negotiate.

Read [https://pragprog.com/book/rdbcd/behind-closed-
doors](https://pragprog.com/book/rdbcd/behind-closed-doors)

Identify and measure the output of your team. Track your performance by how
fast your team creates value. Reduce variance first, then add speed, then more
capacity.

------
agentgt
What I have learned is:

* Typed languages while more complex are worth it (circa 12 years ago I was a heavy scripting language fan)

* Unit tests that heavily use Mocks are almost always a bad sign. Brittle tests suck. Don't increase coverage for the sake of it.

* Get it done and move on. Try not to obsess on little details that add no value.

* "It depends"

* NIH (not invented here) is not always bad. In general it actually is often better (ie invented here). Respect the previous engineers when you move to a new company. There is a reason why things were built the way they are.

* Almost everything can be done in Bash :)

~~~
flavio81
This is interesting. I have programmed in typed languages for most of my life,
including C/C++/Java/C#, but when I went to Python, i did not feel any problem
with lack of static typing.

Or perhaps you mean "strong typing"? Because Python is a "strongly typed"
language: It does not do automatic conversion of types, if types are
incompatible, an error will be raised. Which I agree with.

But it is a dynamically typed language: You don't need to declare types, and,
most importantly of ALL, functions and containers (lists, etc) are not bound
to a specific input data type.

I do think the combination of strong typing + dynamic typing is a great
combination.

Also, amen brother on your thoughts about Unit tests. They have been greatly
overblown these last years.

~~~
agentgt
_> This is interesting. I have programmed in typed languages for most of my
life, including C/C++/Java/C#, but when I went to Python, i did not feel any
problem with lack of static typing._

I have heard this a couple of times from some developers with similar
backgrounds and I have typically found that either these emacs/vim developers
are very disciplined and/or have not really worked with large teams.

Or the language hits their problem domain so well that the benefits of
productivity and terseness outweigh safety (ie research/scientific computing)
and or the projects are small.

But having had 15 or so developers working on a project before Typescript was
invented I can tell you the pain was tremendous.

------
chubot
Shell scripting (which will lead into Unix internals). A lot of programming is
automation and yak shaving, and shell is often the quickest tool to get past
that. It lets you get to the meat of the problem you're actually solving.

Using the same tool for build, test automation, deployment, sys admin,
refactoring, etc. is valuable. Otherwise you are stuck with frothy and
immature domain-specific tools that clutter your brain.

Shell is sort of universal in that C/C++, Go, Python/Ruby/JavaScript, etc.
programmers all use it.

It's sort of like the idea of mastering a single editor. You wouldn't want to
switch editors every year. Likewise I think knowing shell and Unix really well
pays off over the long haul.

~~~
flukus
I agree, I knew how to "use" unix/linux many years ago, essentially knowing
how to run things on a command line, but it's only in the last few years I've
begun to really learn how to use it. For the last couple of years I've been
focusing on doing more shell scripting and learning more of the unix tools
available and I wish I'd invested the time a decade earlier because it's paid
off more than anything else.

It goes from simple things like being able to copy/view production logs in
seconds (instead of fumbling through the file system) to writing DSL's in awk.

I'd go as far as to say we'd be better off teaching kids how to write shell
scripts than any of the current programming classes or the "mail merge with
word" classes that they get taught today.

~~~
chubot
Yes I think that experience is common. Everyone uses shell, but many do it
reluctantly, because it looks old and gross. My first experience with it was
realizing that 'x=1' works but 'x = 1' does not. And also realizing that 'x=1'
creates a GLOBAL variable. Who would design such a crappy language?

Then you get past the surface ugliness and discover its power.

I agree that shell SHOULD be a first programming language. But I don't think
you can teach it to beginners with a straight face. There are too many sharp
edges.

I'm working on both a bash-compatible shell and a new language that aims to
fix this:

[http://www.oilshell.org/](http://www.oilshell.org/)

It would be great if the first thing you boot up to on a computer is a nice
programming language with the capabilities to do practical things like send
mail, scrape the web, talk to hardware, etc. I think of "apt-get" as the
standard library for shell, and it is unbelievably powerful.

~~~
flukus
> There are too many sharp edges.

I wasn't thinking they should learn programming as such. More that they should
learn some various unix tools (grep/sed/awk/etc), learn how to combine them
with pipes and learn how they can save the workflows in a shell script. Maybe
some functions and variables but not if statements or loops. Maybe even do
that in awk instead of bash.

I really love the blog by the way, any tips for putting one together like
that? I'm currently replacing my node based abomination with a similarly
minimalist one built with make, a couple of awk scripts and pandoc. I was
thinking of going even more minimalist and putting a link to firefox reader
mode on the page.

~~~
chubot
Yeah I think learning pattern matching like regexps before learning control
flow and state with variables could be a good thing.

I can imagine a curriculum where you go from HTML (data) -> regex (patterns)
-> full source code. One thing I noticed is that a lot of people who want to
learn to program aren't that proficient at using a text editor and generally
using a computer, and doing HTML first will solve that.

But I also think that regexes have the obvious problem of syntax too. I have
taught regexes along with Python to non-programmers, and it works OK, but the
material didn't demand too much. I think it was basically \d+ and one or two
other constructs.

FWIW one of my goals is to combine bash, awk, and make, although this is sort
of far off:
[http://www.oilshell.org/blog/2016/11/14.html](http://www.oilshell.org/blog/2016/11/14.html)

Awk is an OK first language but honestly it's worse than JavaScript, because
you can't even return an array from a function. Also, functions can't be used
as parameters or return values to other functions.

Although I suppose it has the advantage of being very stable and immediate,
and not requiring NPM and what not. However JavaScript has the advantage of
integrating with the web.

\---

As far as the blog, it's a bunch of custom shell, Python, and CSS that I
cobbled together over the years, and then wrapped in a Makefile. I use
markdown.pl but I'm thinking of switching to CommonMark. I've made several
static websites before so I copied the best bits, with not too much cruft.

It also evolved over the course of the blog. It looks really simple but there
are some details that I spent awhile on.

(And honestly I wish Oil existed so I could write it all in one language, not
shell + make + Python!)

------
mysterydip
You don't have to design the whole thing before you implement. This applies
more easily to smaller teams but there's a continuum between rapid dev and
thinking everything out.

In my game dev it took me a long time to let go of "but I need to create an
elegant/clever solution that covers all my planned features rather than just
what I'm implementing now". What that got me was a lot of unfinished projects
with elegant solutions. When you have time to code, code. Not necessarily the
first solution that comes to mind, but maybe the second. Now you can keep
coding instead of being stuck. Let your mind percolate on the solution in the
background while you code, and while you're doing other things later. It's
amazing how many times the solution will present itself after you implement a
couple different pieces that now need to tie together. Use the power of your
brain's pattern recognition.

Yes, you will "lose" some time in refactoring, but the truth is every project
I've worked on, one-man hobby up to multibusiness teams, has had refactoring
due to scope creep or "we didn't realize this would be an issue until we
implemented it."

It will take time to learn how much thinking vs coding to do (both extremes
are bad).

Final bit of advice: don't listen to the opinions of people as to what is a
good or bad language. Try them out, use the right tool for the job.

~~~
godshatter
This was one lesson I had to learn to progress faster both at home and at
work. Start building now and don't be afraid to refactor later. The caveat to
that is to refactor frequently as things progress. If a function is now
misnamed because it's code changed too much, rename it. If your carefully
thought out code structure just isn't going to work, change it now before it's
a major pain to do so. Don't assume you will get back to it later, you won't.

I don't know how others work, but I had a tendency to try to code the whole
thing in one go. Now I build the skeleton and start fleshing it out piece by
piece, with an end goal in mind. It's very iterative. Do the next thing,
whatever it is, large or small. Build and test. Refactor if needed. Rinse and
repeat. I have to have it roughed out before-hand, but it will almost always
change a bit as I get into the nuts and bolts of it unless it's trivial. Now I
adapt as I go. The design reveals itself :)

------
mattlondon
Most important: don't try and be clever when solving a problem. Simple &
readable code is typically better than clever-tricks or one-line unreadable-
solutions.

Almost-as-important: stay curious.

Apart from that:

\- experiment, make mistakes, screw-up, accidentally do rm -rf / etc etc. Just
make sure you learn from them :-)

\- look at how other people have solved similar problems, perhaps what your
colleagues have done at your job rather than just random github stuff so that
it has more context. See if they did anything that you didn't think of (... or
not!)

\- learn the basics of key data structures and how/why they work (graphs,
trees, hashmaps etc). Learn why they are cool, what the benefits are and where
they could be useful, but remember the most important point and try not to be
too clever and force them in where a loop would do!

\- try to keep your interests/skills/knowledge fairly broad. I've interviewed
people who seemed really good, but turned out to really only know about one
specific narrow field (e.g. they knew _everything_ about ReactJS/Angular/VueJS
(for example), but did not know even the basics of how HTTP works or how to do
a SQL join) so I've had to reject them. As well as programming, learn a
"enough to be dangerous" in unix CLI, networks, databases, web stuff, basic OS
stuff, storage etc.

\- similar to above, try and learn another programming language after you are
competent in one. The learning experience and different perspective will make
you a better programmer in both languages.

\- finally in a slightly more negative vein, the company you work for might be
_nice_ and might be _friendly_ , but the company will have zero loyalty to you
if it comes to layoffs/re-orgs etc. Don't stick around at a company longer
than you know you should just because you feel like you "owe it" to them.

Have fun and good luck!

------
Jeaye
To myself, 4 years in, I would say:

OOP is just a sliver of it and the typical ALGOL-based languages you're
learning are a small piece of what programming can be. Learn functional
programming now. Learn about immutability, referential transparency, and data-
oriented programming. Even if you continue down the imperative, OOP path
afterward, this knowledge will change the way you approach every design.

There is so much more to learn, and so much more I could reveal; you'll get
there, though, and it'll mean more because you did it yourself. Keep at it.

~~~
sk1pper
Totally agree, I learned Clojure early on and wrote a few small projects in
it, and it completely changed how I look at programming.

------
DanielShir
Been doing software for 20 years now, and I think the best advice would be to
keep things simple.

Keep your software design simple, your code simple, your tools simple. Sure,
it's nice to use new and shiny tech for your side projects, but real software
should be done simply and efficiently.

Simple trumps everything else, but it takes a real master to know how to pull
it off. Especially in the context of complicated software requirements.

During my career I've met very few programmers who are capable of doing this
well. It's the true art of the profession IMO.

------
AldousHaxley
I wish I knew earlier that I had enough knowledge to build production quality
applications. I had this idea early on that I had to attain some level of
mastery that was always just outside of my reach, and that the only remedy to
that was learning everything possible under the sun. But after spending years
trying to get to that point, I realized that I could have been building and
shipping products that whole time. If I could do the last decade over, that
realization would have the most profound impact.

~~~
farax91
Thanks for this comment! I appreciate it as it's something that I've been
suspecting for the past year.

------
ensiferum
\- That it's a dead beat job. Get into something with more money like finance
sales or management. There's no real money except for the few rare top 10%
performers at Google,Facebook etc.

\- software is just pure crap. Tools are crap environments are crap libraries
and frameworks are crap. Nothing ever _just works_ but endless nonsense and
meta problems.

\- career progression is shit unless you're really few of those superstars at
an organisation that appreciates technical skills. Or unless you have other
skills such as bullying ass kissing or office politics.

\- regarding code itself. Code as little as possible. Code is very expensive
so you want to solve your problems with as little code as possible ideally
without any code.

\- be aggressively lazy. Don't do anything that really doesn't need doing.
Focus your effort on the few things that really matter. Remember hard work has
no intrinsic value. Engineers in general don't understand this.

\- don't be sloppy. The things you do code while you try to minimize the code
the code you do write needs to be at least ok quality.

------
nf05papsjfVbc
I was working hard to learn more about the language I was using then.

When I look back at that period, I think I enjoyed what I was doing but in
terms of technical knowhow, I wouldn't change much. Of course I know more now
than then but I walked a certain path and I enjoyed it. The process was part
of being where I am now. So, I think I'm happy with it so far.

What, I would like to have had since then: A good perspective on how the
business functions. More empathy.

I've learnt these over time and even in this case, I think learning these was
part of life. I don't really feel like "I wish I had the chance to go back and
change things". I just feel foolish about some things I did then but I
acknowledge that at that time my level of maturity was different from now and
even if I had more (relevant) information or ideas, I'd not have been ready to
use them.

Finally, I'd say that as long as you tend to reflect on what you do and where
you want to go, you'll do fine. Conscious and intentional incremental
improvements take you quite far on the long run.

Good luck!

------
david-gpu
Most companies seem to prefer folks who have a broad base of general computing
knowledge plus one specific area of expertise. This is sometimes called a
"T-shaped programmer". There are definitely exceptions, but is a good place to
start.

Other than that, practice, practice, practice. And get out of your comfort
zone when you practice, don't just do things that are easy for you. You are
only learning when it is hard and it makes you wonder if you might be stupid.

------
wccrawford
My wife hates it when I say this. (She's QA, I'm dev.)

One of my best skills is assuming. I have to make tons of assumptions, and if
I stopped working whenever I didn't know the answer for sure, I'd never get
anything done.

Instead, I make my best guess. If I'm unsure enough, I'll also send off an
email stating my assumption and asking for direction, but I'll still keep
coding based on that assumption.

I am almost always right, and I get a _lot_ more done because of it. Even if
I'm wrong, it's going to be a lot quicker to rewrite what I've done than to
have done nothing and have to do it all after I get the reply.

I'll answer a question you didn't ask, too: What do my bosses wish I'd known
when I started?

That saying, "no," isn't a good answer. Never just reply "no" when someone
asks if something can be done. Find out what they're actually trying to do, or
suggest an alternate way to accomplish it that _can_ be done.

~~~
mattkenefick
"but I'll still keep coding based on that assumption."

That's terrible advice. If you're unsure of what you're supposed to be doing,
you should close the computer and start exploring your options with pen and
paper before doing more damage.

If you keep going based on assumption, you drive halfway across the country in
the wrong direction like in Dumb and Dumber.

Sometimes it's better to do nothing at all than to inflict damage because you
didn't know what you were supposed to be doing.

~~~
omegaham
Personally, I don't view "wrote a bunch of code based on an incorrect
assumption" as "damage." At worst, you have to revert to what you started with
and rewrite it. What were you going to be doing in that time anyway?

Basically, when I hit a roadblock that I can't get around by working on
something else while I wait for clarification, my process is as follows:

1\. List my options.

2\. Pick the best one.

3\. Send an email to my boss outlining the possible options, and note that
I've picked what I think is the best possible option.

4\. Continue coding and know that I might have to rewrite that feature if my
assumption was incorrect.

If you're right, great - it wasn't a roadblock. If you're wrong, you modify or
rewrite... which isn't too big of a deal, as you would have been picking your
belly button lint while waiting for an answer anyway.

------
robotpony
Side projects and life-long learning are the only way to stay relevant.

Stop feeling guilty for not finishing side projects (only finish the good
ones).

Adapt not just your skills, but your learning techniques (you're not in
college any more, and the learning landscape is evolving quickly).

Don't be overly loyal to your company, at least more than is rational (their
loyalty to you is limited to shareholder return and their basic humanity).
This isn't to say you should bail early (as you won't learn or ship anything
real), but value your own career over the number of years you stay with one
company.

Look ahead regularly: where do you want to be in 5 years? It takes 5 years to
get somewhere (like front-end, back-end, kernel dev, UI designer, etc.). As
this question EVERY WEEK, and do something about it.

Make good habits: your habits are your learning and productivity, this
includes the wetware (i.e., you).

------
pjmlp
Make sure you get to learn a bit of everything, don't become too focused only
in tech.

Yes, it is cool to know all latest features from language X or framework Y,
but real work on a company is not only typing code.

Learn to get overview of how software architecture and development processes
work.

Build your social skills to be able to bridge between technical audience and
those not so technical.

Do not work in silos, make sure you get an overview of what everyone is doing,
get domain skills on the business areas the product is targeted for, learn
what customers actually do and want from the product.

------
mnm1
Be skeptical of all the advice and best practices you read about online. It's
mostly fads and fashion with a few useful gems that might not be so obvious.
Implement what measurably works not what some blog or news link aggregator
site thinks should work. Shoot for simple over complex.

~~~
isuckatcoding
Is this suppose to be ironic?

------
giberson
The company (any company and or manager) will try to get away with paying you
as little money as possible. Even if it's below industry/region average, even
if they know you're worth a hell of a lot more. They will offer the lowest pay
bumps they think they can get away with.

You have to ask for more to get what you're worth. And it doesn't hurt to ask,
worst case is they will say it's not in the budget (even then it's usually not
a firm no).

The trick is during your review you have to say you want more. You have to
present a case that you're worth more. And it's not even a hard or complicated
case to make.

If you know what the industry standard is in your area and you're underpaid
say "I think I deserve a pay bump of <gap + 5k>. The average rate for
programmers here is <x> so I should be at least making <gap> and you just told
me I'm doing a great job, so I think I deserve a little more than average."

In all seriousness I'm basing this on past experiences (both myself and
colleagues). You probably deserve more than you're being paid. The company
will easily pay more than they offer by a little and most likely by a lot (if
you're a good negotiator and make a good case).

The key is: ask for more, justify by reminding them you do a good job.

------
eranation
Few things come to mind

1\. To not worry about my code being judged too much. Everyone's code can be
improved. The real art is to know the balance between good enough, and not
contributing obvious technical debt.

2\. Not being afraid to break things. (unit testing helps lower that fear, so
is documentation, single responsibility principle, open closed principle etc)

3\. Assume you will probably never have time to rewrite it.

4\. Assume you will probably never have time to do a _major_ refactoring on it
either.

5\. Boy scouts rule. Due to the above, just gradually make the code a little
better everytime you touch it. You see something bad in the neighboring
method? cleanup, even if you didn't write it, and make sure the unit test
covers that (shows how unit tests are important. It's not just to test your
code, it's to allow people to feel comfortable changing your code when you are
not there)

6\. Unit test (almost) everything on one hand, but feel ok to skip testing a
function that does something so trivial that the test itself is just repeating
the same logic. Also consider mutation testing over code coverage as a metric.

7\. The obligatory - check your own code first before blaming others, Google
everything, if something looks WTF, then you are either looking at the wrong
server, have cache issues, wrong git branch etc... (9/10 of the times)

8\. Use other people's code, avoid NIH syndrome, use open source (with the
right attribution) and don't be afraid to try and contributing back to the
community. Best code is code you never had to write.

------
zubat
My number one piece of programming advice is that you can always find a
simpler way - and if you have R&D time to sink into simplifying your problem,
doing so is a good idea - but actually simplifying is a very hard task and
there is no blogpost tip or design pattern that will do it: it requires
knowing your problem very deeply and being willing to shave a few yaks and
reinvent a few wheels and generally grind away at something that was already
solved, but in a way you find dissatisfying.

If the problem is genuinely original to you, your best bet is to find the
biggest leveraging factors(language, tools, libraries, etc.) and consistently
lean on those to arrive at a solution fast, then pay down the resulting debt
in dependencies, performance and gaps in UX later. This can actually aid in an
R&D effort because reaching a clunky solution quickly will lend a certain
maturity to the codebase and the problem you're addressing. But it means being
willing to read and reuse code that you are personally uncomfortable with and
know does not really solve the specified problem exactly. This is a revision-
heavy process and it's antithetical to what many programmers are inclined to
do - which is to get everything finalized in one shot, drawing on all the
stuff they know is the "best practice" even if it's tangential to shipping.

The more you're willing to allow your code to be "knowingly wrong" in ways
that are easy to call out and to return to later, the faster you can get to
the stage when actually revising it has value. This is why everyone writes bad
code yet some code looks better than others: the good code was bad code that
solved the right problem, then revised.

------
catwell
\- What rhubarbcustard said: get interested in the business. This is
especially important if you work at the bottom of the stack. You must
understand what you users (higher-level developers) want, what the company's
customers want, and what the company itself want.

\- You must decide where you want to go next. The first thing you should think
about is: three years from now, will you take the Manager path (lead a team)
or the Individual Contributor path. If you choose IC, do you want to
specialize, or you want to broaden your skillset and become more of a
generalist? In any case, I would say work on soft skills, broaden your horizon
(e.g. learn new languages, write front-end code if you do backend and vice-
versa, etc) _and_ learn one to three domains very well (look up "T-shaped",
this is where you want to go). But focus on the part you will need the most
for your next step.

\- If you go for the generalist IC route, try to work as close to production
as possible. That means: deploy your code, monitor what it does to the servers
(or machines) it runs on in the wild, watch how real users use it. Also, it is
time to learn how your tools (build system, programming language, OS...) work.

\- If you specialize, pick something with a future, engage with the community,
and if possible with Academia. Sometimes when I talk to engineers and mention
I read research papers they think I'm crazy, but there is no way you'll be
good at an R&D topic if all you do to keep up with research is watch videos
and read popular science blog posts.

\- Have fun. Don't burn yourself out working too much. Keep doing fun side
projects, they teach you things you don't learn in a professional setting.

------
GrinningFool
* When troubleshooting and hitting a wall, there is always sanity in checking the obvious thing that you assume always works. Not a cursory check, but an actual look without assumptions.

* What customers and clients _need_ isn't always what they say they need. Learn to drive at the underlying problem in your discussions with them, and don't focus on what they think the solution should be. While you should always accept their input for the latter as well, keep in mind that most of the time it will address a symptom and not an underlying problem.

* What a customer wants may be related to what they need, but this varies.

* Don't solve problems prematurely. Even simple bug fixes - what is the impact? Are you changing something used downstream?

* Don't assume good tests will always catch all breakages. If they did that, we'd never have to fix bugs.

* Don't trust your dependencies, vendors, platforms, or anything else to reliably inform you of breakages and incompatibilities. They're all run by humans and humans make mistakes.

* _You_ are responsible for shipping working products. If you include a dependency and it breaks, _you_ are responsible for finding that out before your customers do.

------
jaylynch
Learning new things is great but don't be afraid to reach for familiar tools.

Using one or two new things on a project rather than 10 you'll be both more
likely to get somewhere, and more likely to pick up the newer elements well.

------
flavio81
After about 26 years programming -- that is, since i was a little kid, this is
what i wish i would knew, not only 4 years in, but also on my 1st year at
doing actual paid work:

-1. That I should have jumped in straight into Lisp from day one.

0\. That popular technology does not mean that said stuff is the best, great,
good, or even _acceptable_. Example: PHP 4.

1\. That the industry raves about a seriously, seriously crippled and flawed
language (Java)

2\. That "Design Patterns" are mostly workarounds for the problems introduced
by flawed languages (again, Java and friends); not great ideas to be
proselytized.

3\. That Object-Oriented-Programming is not only done in the way of C++ or
Java, but that there are much superior ways to do OOP. (i.e. Smalltalk, CLOS)

4\. That if you want to solve complex problems in a productive way, you need a
multi-paradigm language. Strict-OOP languages or Strictly-Functional languages
will limit you, unless the problem is really suited to it.

5\. That the "Blub paradox" is real. Programming languages are not equal.

6\. Real world (i.e. commercial, production) software should always be done by
experienced people, not by juniors.

7\. A seasoned (say, 8+ experience) programmer can done things 8 times as fast
as a junior (graduate) programmer. I've seen this firsthand.

8\. Dilbert -as others have pointed out- is a documentary. 8.1 Corollary:
Pointy-haired bosses are real.

9\. The customers will always think everything has been done using Excel
Macros.

10\. The salesmen are very important to the health of the company, so don't
make fun of them; rather, make friends with them and help them get aligned to
what the technical team is able to do.

------
ams6110
\- Many things that seem new and innovative today (virtualization, containers
are two examples) were actually invented in the 1970s. Learn some history.

\- Don't get caught up in hype. Technologies go in and out of favor. Not long
ago the idea of writing a application in JavaScript would have been laughed
out of the room. Today the idea of building applications in Perl seems
antiquated. The truth is it doesn't make a lot of difference which language
you use, and no matter what you pick it will probably be less popular in 5-10
years if not virtually abandoned.

------
Malice
* Functional is generally better but don't be crazy about it.

* Have tests but don't be crazy about it.

* Keep your development process as streamlined as possible.

* New languages generally aren't as hard as you might think and they might be the right tool.

* The right tool for the right job can make a huge difference.

~~~
ympostor
I would have upvoted you if it wasn't for your last sentence which is the most
hyped in our industry. WRT this sometime ago I wrote this in a S.E. answer:

I'm a hater of the sentence "use the right tool for the job". Nowadays, any
language can do pretty much anything you want to do with it (except if the
language has recently been created and is still in the early stages, e.g.:
Elm?).

So then IMO these days what you have to do to choose your programming language
is not ask what you're going to do, but know what you want to avoid.

So I use this rule of thumb:

    
    
        Do I want to avoid paying licenses (or resorting to piracy if I'm in the early days of a startup and I don't want to spend money), then I choose a language and a set of tools which have open source implementations (compiler and class libraries) (i.e.: C++11 vs MS Managed C++)
        Do I want to avoid chasing memory leaks for the rest of my life? Yes, therefore I use a language which has garbage collection (i.e. Java vs C).
        Do I want to avoid painful evolution of my project, especially when it's getting larger (wrt easy refactoring and maintainability)? Then I use a statically typed language instead of a dynamically typed one (i.e. TypeScript vs JavaScript).
        Do I want to avoid recent headaches I've had with other software projects in which concurrency was very hard (read: race conditions), then I choose a functional language (to achieve immutability, avoid side-effects, etc.) (i.e: F# vs C#).
    

And it's not that I ran out of questions, there are many more...

But, did you guess it? The questions above are the most important ones you
should ask yourself when choosing the next language to use/learn, in my
opinion. And, did you guess it? This is why my current favorite programming
language is F#: because you can avoid most of the pitfalls that you find in
other programming languages in the industry, and you still can do pretty much
anything with it.

~~~
Malice
Cool :)

I use Python for anything related to text processing or webscraping. I use
Haxe for when I'm doing cross platform game programming. I use React for web
UI / front end work. Erlang for distributed stuff. In each of those cases I've
tried other tools and the ones I prefer now seem much more effective ...

I've never done anything in F#

~~~
ympostor
You can do text processing and webscraping easily with F#. React is a
framework, not a language (you can still use React with F# if you transpile it
to Javascript). You can do cross platform game programming in F# too. And
distributed programming of course.

------
bflesch
\- Don't stress about code coverage metrics.

\- Don't use the next big thing before actually understanding the benefits
only because someone else tells you to. (Looking at you, Angular and Docker!)

\- Stay away from programmers who have strong opinions about certain things.
Most of them can't back them up with skill.

~~~
driton
_\- Don 't use the next big thing before actually understanding the benefits
only because someone else tells you to. (Looking at you, Angular and Docker!)_

I'm curious, what do you not like about Docker?

~~~
bflesch
I followed the call of an employee with 10yrs more experience than I have and
he proposed we move our infrastructure towards docker containers for easier
deployment / management.

Generally containerization of our app was a good step at this point, but we
made the mistake to also put redis / postgresql into docker, which obviously
is an stupid idea if you're trying to scale things. On top of that, docker
networking was a science on itself, and we didn't use any proper automation
tools.

Docker containers kept running out of disk space / memory and it took a lot of
effort to figure out where to place apps. In the end we ended up in the same
situation as before, that some containers were on dedicated machines and the
rest had a kind of hard limit on the max. # of instances per machine.

Our deployment process went from taking 2 minutes to ~10-15 minutes because of
docker registry and extensive jenkins build scripts. It also needed lots of
network bandwith to be transferred to the actual hosts. We had to regularly
remove unused images because the docker registry or our docker hosts ran out
of disk space.

Finally we changed our deployment process to incorporate docker hub because it
was advertised as the premium docker building service. We paid for that
service, but it took between 20 and 40 minutes to build our images. This was
unacceptable for our use case because we needed to fix bugs near-instantly.
Customer support from docker the company and their unresponsiveness towards
our latency problems was another problem.

After the engineer in question left towards a very well-known european music
streaming startup, we finally ditched docker and moved everything to AWS
beanstalk. It does proper version management, config management, auto scaling
and can be defined with a simple json file and some some straightforward cli
tools.

~~~
ianleeclark
I'm really not the biggest fan of docker, but it seems like everything y'all
did was wrong: improper image caching, so you wouldn't have to continually
build the same base images for your services; putting databases in the
container, instead of somewhere else; not using cgroups/docker fundamentals to
restrict space on the container level; storing state (something) on disk
within a container.

~~~
bflesch
You're right, there was a lot of PEBKAC involved. But it was not very
straightforward to do the right thing in that situation.

The engineer in question was very excited about the technology, so we went
with it. In the end it was a great learning on many levels, and I can really
appreciate the kind of problems that AWS solves for you.

------
kenshi
Separate the code you do for work (delivering a product/service) from the code
you use for learning and experimenting.

Keep your work code as simple as humanly possible.

Do your experimentation elsewhere (using the time gained by keeping your work
code simple).

Your future-self, your co-workers, and your client will be grateful.

------
mattkenefick
Read more into things than you need to given the opportunity.

Let's say you need an icon for something, but don't know much about design.
Once in a while, try making it on your own. Learn about the pen tool, image
formats, etc.

Let's say you need a simple SELECT from MySQL. Read more into how they
actually work under the covers, in large-scale environments, or how they
change for MSSQL / Postgres.

Let's say you need a particular jQuery function.. take a few minutes to read
the source and see what it's actually doing.

If you take a few minutes each time you do something unfamiliar, you'll
gradually build up a better understanding and larger skillset without having
to put in too much effort.

~~~
jczhang
That's a luxury that many people probably don't have, as most people have to
get things done under certain timelines.

~~~
mattkenefick
If the timeline is so tight that there's no buffer zone for QA, exploration,
etc then someone isn't doing their job properly.

Either expectations set by the developer, improper buffer added by the project
manager, or lack of push back against the client.

------
agentultra
> What advice do you have for programmers just hitting their stride?

Stop calling errors, _bugs_. They're not cute things that just happen because
all software has bugs. Software has errors. Trust your instinct to leverage
tools to manage complexity and reduce the likelihood of introducing errors.
Lean on sound typing, formal specifications, invariants and property-based
testing. Learn to love restrictions.

Remember: tests prove the presence of errors, not their absence. It's much
more powerful to state, formally, what your software _will not_ do.

Also be creative and play. Take an idea to its extremes and let the haters
hate.

Programming is beautiful!

------
kitd
A reliable build pipeline is your most valuable asset. It could even be argued
that _what_ you build should be determined by whether your build pipeline
_can_ build it. Tinker with the pipeline at your peril. Be very careful what
you do with it. Only when you are sure it works, submit new capabilities to
it.

~~~
AnimalMuppet
More generally, tooling matters. Your editor matters. Your compiler matters.
Your tests matter. Your source code control system matters. Your bug tracking
system matters. Pay attention to pain in these areas. When you keep finding
that it's clumsy or tedious to do something, look for ways to make it better.

------
eps
Invariants is the key concept to writing good code.

Going for a walk and thinking things through yields better code faster than
iterating over it hands-on.

Frameworks are overrated and often a source of ephemeral knowledge and code
bloat. Think twice before committing to a framework or a 3rd party library.

Also, picking a good name for a variable may take up to a day.

------
caleblloyd
Use strongly typed languages for large projects

~~~
nullspace
Adding my corollary, if you must use dynamically typed languages - ensure at
any cost that you split it up into multiple small independent codebases.

~~~
flavio81
Note that a language can be dynamically typed and strongly typed at the same
time. An example of this is Python.

Another example is the latest release of C++, which is strongly typed but now
allows for dynamic typing with the 'auto' keyword.

~~~
nullspace
Thanks for clarifying. :)

I assumed that my parent really meant to write statically typed, not strongly
typed.

------
dom0
That it's not a competition on writing dense code.

People tend to not say what they really want. Become good at finding the
actual requirements. As a CS student, if there are requirements engineering
courses, do take them.

For many projects implementation is the least important part of the project.

Professional conduct is worth _a lot_.

------
Udo
I'm in my fourties now, started programming when I my parents finally relented
and bought me a Commodore at age 10. My point is, when I was 14, things were
quite different - mainly because information was hard to come by and it all
depended a lot on what the people in your vicinity could teach you. However, I
found one similarity to modern programmers starting out:

I wish I had known more about what was actually going on behind the scenes as
my code executes.

In my time, I _knew_ my knowledge was lacking, but being poor and relatively
isolated I had few options. Today, factors conspire to leave new programmers
largely unaware there might be problems in the first place.

Nowadays, we have _way better_ tutorials that teach people how to use
effective programming methods, but we're still failing when it comes to
imparting the understanding necessary for programmers to make mindful
decisions about trade-offs.

I also wish I knew more about persistence and communicating what I'm working
on, it's something I'm still trying to improve. When I was just starting out,
I was working on a text editor, but gave up because I thought it was
superfluous. When I was about 16, I had made a pretty good game (in
hindsight), but gave up on it because I thought it wasn't good enough. My life
might have turned out differently if I hadn't been so shy and uncommunicative
at certain points.

------
intrasight
Find another profession. Unless you really love programming (I do). I am well
compensated, but my contemporaries in other professions are better compensated
- from two-fold to ten-fold.

~~~
farax91
This comment is highly suspect. Do all your contemporaries happen to be
neurosurgeons?

------
novaleaf
I started off in .net, where historically all functionality not provided by
the .net framework is offered at a financial cost.

if you don't have a large team (who can help with bouncing ideas, etc), the
benefits you get from using module ecosystems like npm or pip can not be
understated.

~~~
kzisme
How long did you stay in the .net world?

Was it hard to switch out of it and learn a lot more?

~~~
novaleaf
i moved to typescript (node + webpack)

moving to typescript from C# was pretty easy, and the semi-functional paradigm
of node (Promises especially) was an interesting and caused a beneficial
change in the way I architect applications.

Never used a package manager before moving to Node, so the overall quality of
the stuff found on npm was surprisingly good. still find some wonky/crappy
stuff, but a lot of high quality stuff for just about any functionality you
need, and all for free.

C# would still be very useful if I need a single application to maximize
utilization of a desktop CPU, but for the SaaS stuff I do now, NodeJs + many
small servers (horizontal scaling) is good for cloud vm's.

------
LocalMan
1\. Many managers and customers really do not know what a computer is. At all.
We know they don't understand code. Many don't even understand data. This
problem very slowly dissolves over the decades, as the populace ages and gets
replaced.

2\. Personalities matter more than technology.

3\. Don't let people drive over a cliff, just because it's their
responsibility. Remember, you're in the same car. In a matter of life and
death (of the project, or the company) grab the steering wheel. Of course,
you'd better be sure you know what you're doing.

4\. Out of desperation, some people will sabotage you and then blame you for
it. Sometimes there is nothing you can do.

5\. Always maintain a good working relationship with the person you're working
for, whether a manager or a customer. Chat more often, even if it is
uncomfortable. Especially with idiots.

6\. Some people will be afraid of you, if you have greater expertise. They
need to be flattered.

7\. Seek out and learn from those who know.

8\. Notice I said nothing about technology.

\--------------------------

Beware the changes in technology. I spent decades in an environment where
saving a few bytes mattered, and C compilers were just okay. The coding style
I developed is now obsolete in the era of gigabyte memories, and too hard to
read. Change with the times.

------
willwagner
Here are a couple things that have served me well:

* Own what you own 100%. Be proactive, ask questions so you understand context, and raise concerns along with possible solutions when they pop up.

* Help others when you can. If you are going to be in this industry a long time, your network of colleagues and friends will help you long past your current gig. They can help you solve problems and avoid bad technical choices and when you are ready to move on, they can help you find a new job. The kindness you show others pays off in many ways.

* It's easy to get emotional when you are passionate about a job or a project and that passion can quickly turn into anger. Before sending an inflammatory email, sleep on it.

* Learn the tools of your trade well. Know your editor, debugger, devstack, monitoring tools, deployment tools, etc. I'm a bit hyperbolic but the single best thing I did in the last 20yrs was learn vim well.

* Work hard but pace yourself. Put aside time for yourself to stay healthy.

* Enjoy the moment even when it's stressful. You'll eventually look back on your career and see that the highlight reel features some "against all odds" moments and battle scars.

* Keep learning

------
qdev
Been a developer for over 15 years in the Vancouver area.

Various bits of advice:

1) Pay attention to the severance package when you sign your contract. When
you join a company, you probably aren't thinking about what happens if things
don't work out. But let's say you end up working there for 10 years, bad times
hit, and you get laid off. You don't want to be surprised to find that you
only get the minimal statutory limit. Some companies, I conjecture the larger
ones, will have more generous severance packages.

2) Be cautious about choosing to work in "branch offices" which aren't
involved in key decisions in products/features. You may find yourself limited
in how you can grow, both in terms of scope of technical projects and scope of
career path. This is probably a bigger issue if the region that you live in is
not a tech hub like silicon valley.

3) When I was younger, I was completely focused on programming and "software
craftsmanship". In fact, many of the problems in commercial software
development are people problems -- team co-ordination, process improvement,
empowerment, motivation, etc.

------
Dzugaru
I wish I knew the Functional Way :)

~~~
yuchi
I second this very much. As pretty everyone says, it changes how you treat
code and data. Surprisingly even when they are not the same thing :)

------
Kequc
I wish I had learned to keep my head down and code without the expectation to
release. Because nothing I released in the first 4 years of programming
professionally was good, at least not by my standards today. Try telling me
that 6 years ago.

I was dead set on building entire products, it's why I loved programming. It
was why I love lego. But in hindsight it would have been a better use of my
time to work on smaller projects and ideas. As almost nothing ever got
finished before I was working on something new. I have very little in terms of
a tangible outcome from that time period, and it extended beyond those first 4
years.

Now I wouldn't want to work on a full product before I knew I had all the
larger parts finished first. I wouldn't want to work on those larger parts
before I knew I had the smaller parts those larger parts depend on first.

Programming with this mindset has provided me not only with endless work to
do. But less stressful, more satisfying, easily digestible work with semi
regular tangible outcomes.

------
jargnar
Lots, but these 3 points stand out for me:

* that there are too many things to build and too little time, so don't code for the sake of coding, but solve problems and touch more lives

* that I could have supplemented my coding skills with business skills, and built something that made me money

* that life is short, and coding isn't the only thing to do

\---

Bonus tip: strong CS fundamentals, math > new hip language, new framework

------
tekstar
To really understand what's going on you, learn your tech stack at least 1
layer of abstraction lower than the layer you typically work in.

The biggest wins are where you make a good decision that avoids an entire
class of bugs or an avoid having to write an entire layer of software. These
are also the hardest wins to measure.

Pick something you are genuinely interested in and learn it very, very deeply.
Don't jump around constantly or you won't have insight.

One thing I wish school taught was code maintenance. Most of the code you
write has a shelf life of a few weeks as you fulfill your assignments. Bad
decisions only come to haunt you after months.

You need to watch for new technologies that matter, but 90% of what is new
will not matter. One technique I've seen work is to build a list of people in
the industry you respect and watch what they're interested in.

------
pawadu
Don't be a snowflake.

If everyone are using X, don't go with just Y because it is slightly more
elegant or efficient.

------
stevepotter
Tons of great stuff and I'll add what I can from 15 years as a full-timer
preceded by 10 years as an amateur. I've in settings ranging from a startup I
founded to a large insurance corporation. I'll just keep it to bullet points:

\- Relationships are key to your career. Align with good people and maintain
those relationships.

\- The product is more important than the code.

\- Keep up with the latest tech, but don't necessarily use it.

\- When starting a new job, learn the business first. Understanding what the
product does and why is crucial and doesn't take long to learn.

\- Avoid an adversarial relationship with other departments like marketing and
accounting. Work together with them (back to point 1).

\- Share your wisdom, don't hoard it.

\- When you are no longer curious, something is wrong.

\- Writing code is simply that. Enjoy it, don't glamorize it, and try not to
obsess over it.

------
Joeri
\- If you haven't done so, learn functional programming properly, it changes
the way you think about code. The coursera scala funprog course is a good way
in.

\- Design for maintainability, not ability. Code should be simple, maybe even
a bit boring, and not trying to be too many things. YAGNI and KISS. This gets
rid of a ton of time wasting down the road.

\- When faced with a standard problem, use standard solutions. Use popular
proven languages, libraries and frameworks, instead of the hip new thing. This
saves time which you can invest in the parts that are novel and require novel
solutions.

\- Understand the business value of the code you write, and the political
process that produces its requirements. This knowledge will create
opportunities to earn more, do more interesting work, and have happier users.

------
AnimalMuppet
Learn how to evaluate trade-offs. Not everything is black and white. Given two
alternatives, both of which have advantages and flaws, learn how to decide
which one is better (and why).

Learn a sense of... I want to say "taste", but it's more concrete than that.
Learn what the bad ideas are, and why they're bad. Learn a sense of "that
doesn't feel right" that's technical, not just aesthetic.

Learn what it's like to maintain a two-decade-old code base of a million lines
or more. See what the problems are. Think about what you're doing when writing
new code that's going to create some of those problems.

Learn to document what you're doing to an appropriate level of detail. Take
the time to do so.

~~~
hex13
...and appropriate level of detail doesn't mean every detail should be
documented. Sometimes it's better not to document some technical details
(which will change anyway, and docs will be obsolete soon).

------
yamalight
That nobody cares which language/stack/libs you use as long as it works.

~~~
Kequc
Maintainable and readable is I would say even more important than whether it
works or not. If something works and is not readable it can cause more
problems than it solves. Because it'll wind up in use somewhere.

------
madiathomas
\- Use stable tools(language, IDE, frameworks etc) with proven track record

\- Use tools and programming language that you personally enjoy, not the one
trending on tech sites like Hacker News

\- Focus on mastering at least one programming language

------
skynode
Expand your experience with C#, Python and JavaScript. Nothing gets past those
three (you could add SQL to the mix). Take on as many projects as possible,
preferably with increasing technical (not business) difficulty. If you plan on
starting your own company, get in bed with someone with stellar business
development/marketing skills, while you focus on developing/maintaining the
product/service. Under this scenario, also retain the services of a good
lawyer. You'll be happy you did.

------
blt
I spent too much of my studying effort on being _a programmer_. Mastering
C++11 features, writing SIMD assembly, reading Agner Fog manuals to learn the
x64 ABI and instruction timings. Implementation stuff.

Those things are important, but I focused on them too much. I should have
spent some of that time on higher level math-y skills like machine learning,
numerical optimization, vision, NP hard approximation algorithms,
computational geometry, control theory, etc.

------
kabdib
Learn how to work with other people effectively (not just programmers, but
PMs, finance types, legal experts, etc.) Took me like 15 years to be any good
at this at all.

Get exposure to customers. Try to get involved with decisions involving them.
Many companies actively discourage engineers from having customer contact;
this is bad, IMHO.

Get exposure to the financial side of whatever industry you're in. You don't
need to do official work, but definitely make sure you understand how your
company makes money and what its risks are. (Do a start-up or two; this will
give you a visceral feel for what money is worth assuming the places you work
at are run well).

Read a paper a week (e.g., something from usenix or the ACM, or whereever).
Sites like The Morning Paper
([https://blog.acolyer.org/](https://blog.acolyer.org/)) are pretty good; the
thing is not to get caught in a rut.

If you're doing IT work, get involved in dev work. If you're doing dev work,
get involved in IT. These feed pretty heavily off of each other and
operational background will boost your engineering skills as much as coding
skills will help your IT work.

Things I wish I'd studied harder, earlier: Statistics, practical aspects of
databases and SQL, at-scale networking [didn't exist when I was a sprout],
practical aspects of operating systems implementation (the stuff they didn't
teach you in your course at school), maybe the first six months of an EE
course . . . I could go on for quite a while. The good news is that there's no
way you'll run out of stuff to learn, not in your entire career, and it's all
(usually) applicable at some point.

------
Const-me
There’s no universal criteria of code quality. The same source code can be
terribly bad for one project, and 100% perfect for another one. Don’t just
blindly trust what other people say or write about the subject, when possible
ask them why they advice stuff.

Learn algorithms and Big-O just enough to pass job interviews, deeper
understanding of these is nearly useless in practice, at least outside few
narrow niches.

Learn to design and code safe and efficient multithreaded software. While not
often asked on interviews, you’ll do that over and over again regardless on
languages and platforms, because nearly all modern CPUs are multi-core.

Learn to use other people’s libraries and third-party tools. While their
quality vary, good ones can save you tremendous amount of time. BTW, an IDE is
one of these tools. Just don’t forget about costs (some might be too expensive
for particular project) and licensing (some are GPL).

Don’t afraid to change jobs. Just that you’re working with nice people is not
a good reason to stick to your employer. Make sure you learn new stuff, skills
degrade over time as the industry moves to new technologies and platforms.

------
sebringj
By the sheer number of responses here, this is a testament to how personal
each coder's experience is and how much they value it unto itself. Coders care
about the work they do and especially in the beginning find their choices to
equate to who they are, tending to find unwanted changes or revisions to their
code by others' hands as annoying or encroaching upon their precious domain,
at least for me.

To this day, I still get very annoyed when someone takes what I have done,
completely reworks it or even throws it away, doing something else that IMO is
more complex and difficult to work with. My values have shifted from doing the
quick and custom style to moving more toward standards and TDD in a style that
everyone can pickup easily and understand.

This has made my work so much more productive in getting to the final
production quality by a factor of not less than 2. In my youth, I spent 99% of
my time fixing code as it broke. Now, I unit test and in many cases, end-to-
end test with TDD frameworks providing myself with a much higher probability
of success when pushing to production.

------
quantumhobbit
There are sexy tasks and unsexy tasks. Don't be a hero and do the unsexy tasks
for the good of the team or company. You will become typecast and soon won't
be able to get any of the sexy tasks. Your boss will stop investing in your
career and you won't be competitive when you try to get a new job.

You actually have to play politics to be allowed to do your job to the full
extent of your abilities.

------
twsted
As in all the disciplines, the most important 'tool' is the experience, and
that - ça va sans dire - needs time.

That said, I think the best advice I can suggest is _Divide et impera_ ,
[https://en.wikipedia.org/wiki/Divide_and_conquer_algorithm](https://en.wikipedia.org/wiki/Divide_and_conquer_algorithm)

------
dahart
In retrospect, I wish I had spent half as much time learning how to be better
at social and team-building skills as I did learning programming. Both as a
team member, and as a manager.

During my career I've spent a lot of time resisting and rejecting the overhead
of time spent reporting what I'm working on and to some degree careful
planning for the future. Like a lot of programmers, it only takes one or two
short meetings a week before I feel like it's too much and meetings are a
massive waste of time.

My first real job coding CG effects at DreamWorks, I got a black mark in my
personnel file in my first 6 months for complaining about being asked to show
my progress once or twice a day. It was during a 3-4 week coding project, and
it took about and hour to prepare for dailies, so it seemed to me like I was
being asked to sacrifice 25% of my productivity, to the detriment of both me
and the company.

A few years later I'd been working on a shot for a month, thought it was
exactly what they had described, and pretty good and close to done. But it
kept not being finaled. Three months later when the director approved it, I
looked back at what I thought was near done month 1, and it was crap. I
realized that we sit in meetings and describe in articulate detail what we
want to achieve for hours, everyone agrees vigorously, and people still walk
out of the room having completely different ideas. I realized I need the
overhead for course corrections for what I'm doing -- I will veer too far away
from what others want without fairly continuous feedback. After seeing that in
myself, I see it everywhere with others, programmers working too long by
themselves will make what they want and not what the team needs.

Communication is what I want to improve. Not more of it, but how can we make
it better?

I also wish I'd gotten out of C++ and into web earlier. ;)

------
kenshi
Write some documentation.

A high-level design document of any significant system and subsystem is worth
its weight in gold (or: programmer hourly rate * time to get up to speed on
system).

This documentation will also help you in a years time when you need to either
maintain that system, or need to remember how you built it so you can build
something that is 90% similar to it for another project.

------
jmcgough
(Not at 10 years, but...)

Take care of yourself. You are not a robot. Showering, skin care, hair care
and sleep are important. It's worth it to go to a good stylist regularly. If
you're happy, you're doing better work, and most importantly you're more
approachable to your coworkers.

Don't ignore mental illness. It needs to be dealt with aggressively, on
multiple fronts, until you've figured out the right ways to cope and be
functional.

You can't just code alone in a corner. You need to socialize with your team,
or you'll miss out on the meta knowledge (patterns, styling) that's being
passed around the team.

You _are_ smart. Give it a few years, and those impossibly talented and
brilliant senior programmers will be your peers.

Don't be afraid to refactor and change code. The person who wrote it didn't
know what you do now, because business requirements are constantly changing.
Be aggressive - sticking TODO statements in code isn't going to fix technical
debt.

------
kobigurk
Enthusiasm is great, but over-working and burning out is easy to get to - so
make sure you take care of yourself.

Be delivery-oriented and don't be afraid to make design mistakes - it won't be
perfect on the first time anyway.

Know more than your niche, get out of your comfort zone once in a while.

Respect your co-workers - even if they make mistakes, it's OK, you will too at
some point.

------
gry
It's never a technology problem. It's always a people problem.

------
ainiriand
Leadership and conflict solving through empathy. Also public speaking.

------
tchaffee
1) Wherever you work, find at least one good mentor who is better at coding
than you, and who can hopefully teach you a little about soft skills too:
negotiating, company politics, making presentations, and so on.

2) Most companies have zero loyalty to you. They will fire you and thousands
of others the minute they are in trouble, and without hesitation. If you're
loyal to a company it's a one-sided relationship. Take care of yourself, the
company will be fine without you.

3) Age discrimination exists, and it is VERY harsh. And your brain will
eventually slow down while technology ruthlessly and quickly marches on. You
might find it tough to keep up due to either or both of those factors. Save up
early. Be able to retire by 45. Keep working if you still love it.

EDIT 4) Get EVERYTHING in writing. Happened in a conversation? Follow up with
a simple email "Just so there are no misunderstandings, I wanted to confirm
that..."

------
epaga
"Clever" usually ends up being a negative word when it comes to programming
solutions. "Elegant" and "simple" are far more important. Keep searching until
you find a solution that feels elegant and simple. If you're sure there is
none, only then write clever solutions.

I also wish I had known to buy some Bitcoin.

------
tjansen
Make sure you're not the only person who can work with your code. Make
yourself easily replaceable, on a project level.

Otherwise you will get calls during your vacation; you may not be able to work
on other projects, switch teams or even get promoted - or if you do, you will
still be supporting the code you wrote years ago on the side.

~~~
ifend
This. Ensure you have someone that can replace you so you can quickly move on
to better things when they come up.

------
galdosdi
I wish I'd realized that I wouldn't enjoy it anymore and be bored of it after
15 years, and that I invested in a skill that despite paying well does also
put me in the line of fire of cardiovascular disease, carpal tunnel, feeling
like a zombie from sitting alone in front of a screen all day, and general
burnout from death marches and the like.

It took me a long time to get this bored of it though, so if you are similar
you should be OK for a long time maybe.

If you get paid well, don't spend to match your income. Save as much as you
can. You never know if you'll lose the drive 10 years in.

I know the world of code can be very exciting, but after a lot of work you
start to see there is nothing new under the sun and you fix and write the same
old things in different forms. And most of the problems you grapple with are
man-made, like the idiocy of using languages without static typing voluntarily

------
annnnd
That you can learn _anything_ the way you are learning programming - by
reading, trying, failing, trying again, debugging, trying again... You want to
have a successful software business? Learn _business_ , not just programming!
You want to grow your business? Learn _marketing / growth hacking_!

------
mmphosis
"4 years in" I am not sure what "in" means, but I started getting paid for
programming in 1984. So, what do I wish I knew in 1988?

I think you already said it: "I'm also realizing there's SO much more to
learn."

Don't stop learning. It was probably around 1988 when someone suggested I look
into Lisp and I dismissed the comment at the time, although I did look into
AI. I do wish I had known more about Lisp, not necessarily programming in
Lisp, but just the knowledge of the concepts that come out of learning Lisp:
garbage collection, stacks, lists, trees, macros (not the terrible C macros I
was using at the time but Lisp macros), parsing, code generation, profiling,
the benefit of programming in a more functional way, and I am probably missing
a lot of things here I take for granted. Don't stop learning.

~~~
flavio81
My feelings too. I should have entered Lisp earlier. I have wasted many years
of my life with Java. Then C# was a relief. Then Python was much superior in
the speed and easiness for doing useful stuff.

But the power of Lisp (Common Lisp, in particular) goes far beyond all those.

------
Clanan
I've only developed professionally for ~6 years but here's the mandatory non-
answer: make sure you prioritize "life" things too, especially when doing
full-time plus side projects. My kids are still young but I already wish I had
spent even more time with them when they were teeny.

------
junkilo
1) Learn one thing really well and stick with it until you master it. Human
confidence isn't wired to derive satisfaction from breadth of skills. The
stronger single skills you develop, the easier it becomes to develop context
and understanding as you add to your skillset.

2) Get solid on the basics and stay current: data structures, algorithms,
computation and basic operating systems. Without these you'll never reach high
levels of competency.

3) Develop boundaries. I've seen stellar developers reduced to a pile of
depression and anxiety by poorly trained managers getting them to overcommit.
Learn to know what you know well and what you do not know well. Push the rest
back onto your manager and make them do their job.

4) Take time to enjoy and savor this time. We're in an age of technology that
has never before existed.

------
random_coder_nz
The most important lessons in coding have little to do with coding and a lot
to do with people - code is written for people not the computer.

The more you know the more you will come to understand you don't know much;
that is both good and bad (Dunning Kruger vs Imposter Syndrome).

Every time you think you are the best in the room, look around and ask
yourself are you overestimating your knowledge. If you are still the best in
the room, maybe it is time to find a room with smarter people.

Not every solution requires code / technology.

The best code is easy to read and even easier to delete.

Give your code to the most junior member of your team - if they struggle with
it you need to make it simpler.

There are many many lessons like these around - the single most important one
- always be open to new ideas no matter how much they oppose your current
beliefs; strong opinions, weakly held.

------
royjacobs
That while C# is probably a better language than Java, the Java ecosystem is
so much more innovative and open.

~~~
romanovcode
Yeah, I don't buy it. Especially after seeing what they are planning on
Build2017.

Also, it's completely open-source.

------
giancarlostoro
I'm more or less on the same boat. My advise is, don't let it overwhelm you,
learn as the need arises (or you have a burning interest in something). At
work I've done a handful of languages (web development can do that quite
quickly these days) and I've not been here a year. On my own time I experiment
with D and Rust, and maybe soon Kotlin. Those are my languages of interest, I
don't do something every single day for hours on end, but now and then I open
up an editor and play around with one of those till I find something to build
on my spare time. Chances are as you get new jobs you'll learn new languages
and stacks, so don't be overwhelmed. How many co workers do you see doing 50
projects in 50 different languages and stacks all at once? ;)

------
jecxjo
Everything should be done in moderation. Eventually you learn how to only put
forth the amount of energy required of a task. While it is fun to do things in
new and interesting ways, the name of the game is least time spent.

This also applies to how much energy you put into your work. I started out
trying to meet crazy timelines and for the most part I did it. But eventually
it became the norm and I couldn't keep up. It took a lot longer to get
managers to understand that nights and weekends are not sustainable.

Lastly I would have jumped ship sooner. I've been working for the same company
for 11 years and now that I'm in the market for a new job, no matter how much
I tried to diversify myself within the company, I don't always have specific
skill sets these new positions are looking for.

------
yehohanan7
\- LISP

\- "how to solve it" by george poyla

\- asking more "why"s to problems

~~~
randcraw
True. I'd add: think more about _outcomes_ and not products. Software enables.
It should improve the life of the user.

------
bartwe
That making a lot of crappy stuff is a much better way to learn than making
one thing perfectly.

------
moomin
Some really simple technical principles:

Explicit is better than implicit. All state is hard to reason about and debug.
Code that doesn't have tests is brittle. Short code is better than long code
and no code is better than both. Inheritance of implementation is hard to
reason about.

Some technical advice:

Write comments about why you're doing something, not how. Write lots of
comments. Check preconditions, especially nulls. Write explicit error messages
for every failure: you'll be searching for them one day.

One non-technical thing:

Understanding the problem you're trying to solve is often better than any
technical knowledge. Understand the business processes, the users and the
people and you'll find you're vastly more effective.

~~~
continuational
I would give almost the opposite advice:

Whenever you feel like writing a comment explaining why you're doing
something, step back and consider if you can refactor the code so that it
becomes self documenting. Code and comments get out of sync easily.

Instead of checking for preconditions, step back and consider if you can make
the illegal states unrepresentable. If you have a decent type system available
(sum types, no nulls), that's often straightforward.

The best peice of code, the best test and the best comment is the one you
didn't have to write because of good design.

------
czue
This might sound cheesy but mine is to pay attention to your inner state of
mind. If you love coding then don't let yourself get drawn into management
just because it's "advancing your career", and likewise if you find you enjoy
making a broader impact through managing a team or expanding your skillset
then do that and be okay giving up code.

If you start going down a path that makes you feel less happy, take a moment
to ask yourself why that is, and what you're getting from that tradeoff. If
you can't answer that question in a way that makes your inner mind happy then
figure out a way to change course. And a slightly higher salary is not a good
reason.

------
MichaelMoser123
In order to get somewhere you have to commit yourself and invest a lot of time
and effort; however if you overcommit then burnout and disenchantment will
follow... Now finding the right balance is hard, if you know some good advice
then let me know (I still haven't found it after 20+ years in the profession).

It is important to meet the right people that one can learn from (who are
ready and able to share their knowledge).

Spending too much on sites like HN/slashdot/reddit is a bad idea. Again one
has to find the right balance (and the right sources of information that do
not turn into time sinks), balance is important like with the other stuff ...

------
nils-m-holm
Before becoming a professional programmer, be sure you understand that
programming for recreation and for money are two completely different things,
otherwise the latter has a big potential to take all the joy out of the
former.

------
oxryly1
Most programmers (you included) will tend to build things not because they are
the correct solution for the problems at hand, but because they are
interesting and just happen to solve at least some aspect of the problem.

When this happens repeatedly over time in an organization you wind up with a
large, complex codebase that tends to solve problems in pieces and at scales
other than the correct level (i.e. as the user experiences it).

Usually, the best approach to solving the largest portion of the problem at
hand does not involve writing code, and if it does, it won't be code you are
interested in. Such is life as a programmer.

------
logfromblammo
Don't get so involved in technical details that you don't pay attention to the
business.

Your company _will_ try to stab you in the back one day, so you have to keep
an eye open for it. Always reserve 1% of your career energy towards looking
for a new job greater than or equal to your current job. Whenever you find
one, take it, and just keep on looking. (If you do contracting, never let any
single client represent more than 50% of your total income.)

It's harder for them to hit a moving target. And even if they do get you,
they're more likely to just wing you instead of hitting something vital.

------
Nursie
If you're any good, and confident in your abilities, you can go contracting
for the (comparatively) big bucks without needing over a decade's experience.

Most people are not that good, or confident, even among higher earners.

------
lackbeard
This advice is situational, but if you find yourself on a team with some
experienced, talented, productive programmers, pay attention to what they're
doing and learn as much as you can from them. (Things like: what they choose
to spend their time on, what trade-offs they make, how they evaluate
technologies, when they listen to customers and other stakeholders and when
they ignore them.)

Most programmers are short-sighted, selfish, and lazy, so it's unusual to find
yourself with a group earnest talented people who have experience. Appreciate
it, and take advantage of it while you can.

------
cbanek
Learn how to test your code. I'm not just talking about unit tests either, or
TDD, which I find are nothing more than buzzword bingo.

Take your testing as seriously as your development. Not just in the details of
the implementation, but understand your user and your use cases. Write end-to-
end test suites, integration tests, and unit test complex logic.

Don't be one of those "unit testing is enough" or "I TDD all my code." I find
the more time people spend on little testing, the bigger problems seem to fly
through to prod.

------
porker
People who shout in your programming community that there's "one true way" to
do something and gain 'guru' status will either disappear or be telling your/a
different community a different "one true way" in 4 years's time.

I wasted years trying to do things "properly" (completely pure OO in my case)
when I could've been releasing software, and wasting effort anguishing over
why I thought differently to the gurus.

Now I have no time for programming fads. But try not to go too far this way -
it's easy to be too late an adopter too.

------
tonescience
Sitting in front of a computer 60+ hours a week is not great for your body.
Take the time to understand good ergonomics, buy yourself a great keyboard
(like the Kinesis Advantage), and ditch QWERTY.

~~~
inimino
> Sitting in front of a computer 60+ hours a week is not great for your body.

The next sentence should be: So _don 't fucking do that_. You do your family,
your employer, your coworkers, and most importantly yourself no favors by
working 60 hours a week in front of a screen. It doesn't matter if you're
working for yourself or someone else.

If you think otherwise, you've been brainwashed.

~~~
tonescience
Or if you are not too "brainwashed", you can decide for yourself how much time
in front of the computer is too much.

~~~
inimino
We know it's unhealthy, unproductive, and unsustainable, and people do it
anyway. There is pressure to overwork, coming from employers and from a
misguided urge to keep up, and all kinds of addictive behaviors that keep
people in front of the screen. This is a widespread problem to be addressed,
not just some preference for each individual to decide.

------
Blinks-
I inquired about this to a friend of mine who was mostly self taught at first,
he has now past the 10 years experience mark but is just finishing up school
in between freelance jobs. One of the things he told me was to take a
terminology/vocabulary class, you probably know most of it after a few years
experience but even a slight misunderstanding in diction can have serious
implications down the line. I was surprised how much I learned and how
beneficial it was to the conciseness of my code comments.

------
1001101
\- Find the tools that work with you to improve quality and productivity, for
me that's: Syntastic Vim plugin (with 4x C/C++ linters), cscope, valgrind,
asan

\- If you do something more than once, automate it. Create a script, write a
bash alias, something

\- Keep reading; Go to conferences; Get a subscription to O'Reilly Safari -
worth every penny; It's easy to become a dinosaur as a programmer

\- Step through every line in your code - TDD is a good way to do this
(corollary: figure out a good TDD methodology for your workflow).

Good luck!

------
raintrees
How important documentation is. Having to go back to code I wrote years ago,
figure out what I was trying to do, relearn specific add-ons/libraries that
were only used for that project, then figure out all that has
changed/abandoned in the intervening time, avoiding the temptation to start by
refactoring... Very difficult, and very easy to be doing unprofitable work
because my state of programming mind is so much different each time than the
project that is now years older.

------
lwlml
Sleep and high-intensity exercise are underrated as productivity tools.

Anger is best solved by not ruminating about it---the catharsis hypothesis is
busted.

Read other people's source code of interest, closely.

Increase focus/limit distraction by limiting the work-in-process with Kanban-
like systems.

Assembly language matters but abstractions can multiply the power of your
systems. Conversely, too many layers of abstraction is a design-smell.

And soft-skills care not what programming language you speak.

Independently of work, learn a new language once a year.

------
strictnein
This is more true now than it was back 10 years ago, but there is simply too
much tech out there to have a solid understanding of it all. Be okay with not
understanding the latest thing or cool new field because many times they fade
away, no matter how popular they seem to be, and you simply can't understand
all of it.

On this and other forums it seems like everyone knows everything, but that's
only because there's a lot of people here.

------
makmanalp
1) When adopting tools, methodologies, and practices, think about /why/. Don't
use things because they're "good practice", look at what problem they solve,
see if they solve _your_ problem, adopt or adapt accordingly.

If you're going to use design patterns, great. But don't argue about the exact
official gang of four definition of the facade pattern - a more productive
conversation is about which specific bits of the pattern help you solve your
problem and which are an impediment.

Tests great, but when you're just starting a brand new project where the
behavior and spec is changing as you build and learn, should you suffer
through brittle unit tests because "not testing is bad practice", or could you
perhaps start only with integration tests, and wait a little bit until you
start doing anything more granular?

Complex git branching / release / hotfix / etc schemes can be great in a
larger organization, but when you're on your own, do you really need all of it
or is it too much overhead? If you don't have a staging environment, should
you have a staging branch?

Summary: a) Am I actually trying to solve a problem? What problem am I trying
to solve? b) Is this thing going to solve _my_ problem or a problem that I
don't have? c) What can I change so it /does/ solve my problem?

2) In a large enough codebase, there is always bits that are shitty for a
variety of reasons involving bad programmers, bad practices, no practices, bad
requirements, terrible deadlines, old tech, whatever. You don't /want it/ to
happen, but it will. Or perhaps you'll be dropped into that codebase, and so
you'll have had no say to begin with. An unappreciated part of the practice of
software architecture is about containing current and future shittiness,
stopping it from spreading, managing the risk around that, not allowing that
to impede current development, setting up a surrounding architecture, getting
people on board socially to do the right thing, having a good plan to replace
it and acting on that. "No new code until everything is clean and tested"
sounds so valiant, but I'd like to see it happen in a 100 person organization
with bills to pay. Alternatively, after you've contained things, then you can
feel free to adopt such policies at a smaller scale within well-defined
regions of the code.

------
andyjohnson0
Most of the code you write will probably be dead and gone within a few years.
Get used to not being able to point at something and say "I did that."

------
f1gm3nt
Learn soft skills such as communication with different stake holders. You'll
need to be very good at explaining tech concepts to non technical people.

------
rudyrigot
It's all about business/user value. You're not solving useful problems if
they're solely technical and don't solve anything useful for someone else.
Solve business/user problems with technical solutions, and (1) people will
like you more, (2) feeling useful is gratifying, (3) you'll feel more
productive with less code, since you'll be focusing on the right output vs
code.

------
arnoooooo
I wish I had taken the time to understand LISP earlier.

~~~
johnfn
Why?

~~~
flavio81
Lisp is by far the most powerful programming language out there. In fact, Lisp
is not a language, it is more a philosophy:

\- If a language's syntax is written using an structure that the language
itself can easily manipulate, \- in such a way that the source code can
generate new source code, using the full power of the language (no
restrictions), \- in a easy-to-program, straightforward way,

... then you practically have a Lisp language.

As somebody important said: "Lisp is the programmable programming language".
This is the key difference among the rest of the languages.

I have spent about 26 years programming and only this year I set myself to
grok Common Lisp. The power of Common Lisp, and in particular its object
system (CLOS) makes languages like Java seem like ugly toys for miserable
people.

~~~
johnfn
I understand that lisp has power but I remain unconvinced that power in any
way correlates to writing better programs. A lot of the utility that e.g.
static typing provides is a sort of convention of how to write code such that
we can then use tools to do the mundane work of verifying that our code is
accurate or refactoring it. In other words, lack of power makes code note
maintainable.

I don't doubt lisp is fun and easy to write, but power doesn't have much say
when it comes to refactoring. That's where convention wins out. How is
refactoring 10k lines of lisp?

~~~
kazinator
Refactoring 10K Lisp is very good.

Lisp compilers provide diagnostics about code; it's just those diagnostics
aren't the arbiter of whether or not something gets to execute.

------
Zelphyr
How much you can learn, and how fast you can learn when debugging. Now,
whenever I start with a new company, I make it known during the interview
process that I expect to spend _at least_ the first 2-3 weeks (preferably
more) doing nothing but fixing bugs. That's the best way I've found to get a
solid understanding of the codebase.

------
davotoula
Test driven development.

Continuous integration first - first line of code second.

Understanding that writing code is a small percentage of my day - then there
is testing, designing, writing docs, deploying, automating, infrastructure
configuring, discussing with stakeholders,

Learning multiple languages - especially from different families (procedural,
functional, scripting, low level, etc).

------
joeblau
More respect for testing on larger teams. Code regressions cost teams I've
worked on 1000's of hours of debugging.

------
weego
That almost every job you get will highly prize pragmatism and general problem
solving skills over pure technical know-how

~~~
johnfn
...except in the interview.

------
gits1225
I wish I knew the importance of working on an idea that is mine. You'll not be
influenced by external pressure or constrains. You can build it how it should
be built according to you. Along with following the right people and working
with smart people, this habit has helped me improve my skills across different
domains.

------
cdicelico
I wish I had known that programming was something I wanted to know how to do,
not something I want to do with my life. :P

------
ivan_gammel
Go beyond the code. Learn UX, DevOps, QA, look at other engineering
disciplines. Improve soft skills. Learn management and laws. Learn design and
arts. You may not become good designer or manager, and you'll probably never
be a lawyer, but everything can contribute to your success on many different
stages of SDLC.

------
sevensor
Hopefully you're three years into the "Teach Yourself Programming in Ten
Years" program
([http://norvig.com/21-days.html](http://norvig.com/21-days.html)). If not,
Norvig's advice is short and to the point, and well worth following.

------
jbpetersen
If you dig into the origins of a buzzword, it's highly likely there's a very
valuable concept hiding underneath the accumulated cruft.

Had I known this sooner it would've sped me along considerably towards finding
a lot of cool things that give me more motivation to program.

------
eggie5
Cracking the coding interview will get you a job at any tech company for
pretty much any position.

------
NicoJuicy
Except for using what you know, and that tech doesn't really matter.

I would add that you shouldn't be afraid to use new tools is they get you to
the end faster. Common case for me: I use c# for almost everything, but nodejs
wrapped in an API for crawling

------
awjr
To have read Code Complete (now edition 2). I'd add Clean Code to that list as
well.

Looking back 24 years, I'd also add, to be more involved in the local hacking
community and participate in hackathons.

Anybody can code, but to make a difference, you need to network ;)

------
tpae
Be nice to the people that's taking their time to teach you. Don't take their
time for granted.

Throughout my career, programming mentors have shaped me to be who I am. I've
learned most of best practices through code reviews and from my mentors.

------
dgregd
Take care of your health. Sitting long hours damages your spine. I learned
this too late.

~~~
b0rsuk
As someone after a spine surgery, I can't agree more. I have a tendency for
discs to slip. The only way I can treat it is core exercises, 4+ times a week
for up to 1 hour. While I now look impressive with shirt off, the sheer
monotony of these exercises stinks, and it doesn't remove the problem
completely. I'm like a cockroach now - I can only rely on my exoskeleton.

If I knew these exercises before the operation, I could have prevented it.
Leading a healthy life, proper posture when sitting, physical exercise (for
spine - especially swimming) are extremely important in the long run. Your
spine degrades with time, load and improper posture. Sitting in general is
unhealthy. Humans didn't evolve for sitting. I'm more comfortable lying or
walking. People ask me to sit trying to be polite, but it really makes me less
comfortable.

------
kevrone
I wish I had more systems knowledge (ie: better command prompt skills) and I
wish I had spent more time learning about networks and ssh. Some of those
concepts are really not that complicated but just _seemed_ impenetrable at the
time.

------
tmaly
If you end up staying a few more years at the company, the code you write
today, you will have to work on again at some point.

Since we read code more often than we write it, put a little extra effort into
making your code easier to understand.

------
blinks
It's more important to make code readable than clever, and more important to
be simple than fast.

It tends to be pretty easy to speed up readable+simple code when you need to
do so, but fixing broken fast+clever code is much more difficult.

------
toexitthedonut
Something more popular than PHP.

I got into web development in the last 2000's doing PHP backend development
and CMS work, and now everyone seems to have gotten into more opinionated dev
environments that really involve anything but PHP.

------
grandalf
Maintain a perspective of openness about the state of what you've built. At
any moment you might realize that a smarter person could build it in a few
hours using a better abstraction. That smarter person might be you.

------
sidcool
I wish I put more time in thinking about the problem rather than jumping on
solution.

I wish I designed a testing strategy for the feature I am developing.

I wish I learnt and embraced good engineering practices and spread those in
the organization.

------
solomatov
Focus on learning fundamentals, i.e. things which will be useful in 10 or 20
years, like math, machine learning, algorithms, different programming
paradigms, etc, instead of pursuing a fancy framework of the day.

------
Xeoncross
Pick the language and tools everyone is using. They will improve quickly and
where least expected simply because so many people are using them. A great
mind will think "Hey! I could ...." (and do it).

------
sgt101
Your code should not be optimised to execute algorithms, it should be
optimized to communicate intent. You write code so other people can read and
understand it. Most other people are you, in six months.

You will thank me.

------
arwhatever
The sooner you accept and acknowledge that you can't find an entire project's
code in your head, the sooner you can start incorporating that awareness into
the design decisions that you make.

------
velebak
Software Development as a career requires a commitment to a continuous cycle
of learning (and teaching.)

Your skills will grow, but the churn of tools and techniques will have you
relearning things on a regular basis.

------
JohnDeHope
I was hired into my first cubicle around 1999, doing asp classic web dev. I've
gone off on some side tangents here and there, but have more or less been
building web apps using MS technologies to this day.

It's not them, it's you. Any problem you have is your problem and the solution
is something you're going to have to do. Be it a compiler bug, deadlines blown
through by partying interns, shoddy code written by contractors, insane
deadlines imposed by self righteous VPs, etc. All of these problems are caused
by you. You took these jobs. You fed the mice cookies. You didn't say no. You
didn't spruce up your resume and blog on LinkedIn. You are the only person
that is ever going to try to help yourself, so if you don't like what's going
on, there is no where to look but inwards.

Every line of code is a devil, waiting to bait you. Every curious syntax,
handy shortcut, convenient convention that only you and the few who read the
docs will know about, is bait in a trap. It's better to write less code,
simpler code, and code that eschews advanced features in favor of being
obvious. Imagine yourself having not slept for 24hrs, being drunk, with a CRT
monitor at 640x480, typing on a keyboard covered in elmer's gluge, and then
write code you could debug that way.

In about 20yrs on the job I don't think I've ever seen a situation that truly
called for more performance. I've seen bad processes that were too slow
because they were bad, and I've seen inner loops that needed to be unrolled,
and I've seen (written) code that was hitting the database in ways that were
totally bonkers. Slowness is mostly about bad decisions earlier up in the
decision tree. Unless you're writing trading algorithms or video games, you
likely have no use for your program to run any faster.

Prefer bad working code over good code that still isn't producing any useful
output.

Your choice and relationship with your spouse will have more of an impact on
your career and long term happiness than anything in technology. Take care of
home first. Then go to work.

You are going to need a few key side skills: public speaking, making small
talk at parties, presenting to people above your pay grade, technical writing,
etc. These are key differentiators that are more valuable than being able to
write more or better code.

When you're feeling burned out, take a day or two off. If you aren't able to,
or you do and it still doesn't help, then something deeper is wrong.

Cutting down on the drama of deploying and maintaining production software is
just as important, maybe more, than fun during development. Yeah some
languages are excrutiating to code in, but they run smooth, and that's worth a
lot. And some languages are a lot of fun in the editor but a bitch on the
server, avoid those.

Steal ruthlessly. Anybody who is doing anything cooler or better or faster
than you, buy them lunch and ask them what they're up to. You don't have to
follow in their footsteps, necessarily. But at least being familiar with other
ways of accomplishing things really helps broaden your horizons when
brainstorming or thinking about problems.

It's okay to take long breaks to do something else. You can always come back.

Make friends and stay connected. Your rolodex is your escape hatch if things
get ugly.

You are a business. The product is yourself. You're the founder, CEO,
president, etc. When you answer the phone, do so as the CEO of You, Inc. Ask
yourself: if I was a business person, and one of my employees was representing
my business to my customers the way I am doing now, would I fire that person,
or promote them?

Knowing which rules are actually enforced and which rules are just for keeping
chumps corralled can really help your navigate a bureaucracy.

Making friends with people who make and enforce rules can get you out of
following a lot of those rules, or just provide back doors into the processes.

You pick your boss and at work that is likely one of the most important
decisions you'll make. If you don't like them, find a new one.

------
anovikov
The world of coding is cynical and this is a much dirtier business than it
sounds, you can get away with almost everything.

Apart from startups: in startup, technical bullshit is replaced with business
bullshit.

------
ctocoder
I wish I knew that I should keep practicing all my math skills I spent 5 years
perfecting, to loose them after 10 years and now I need it to truly understand
ML instead of using API's

------
michaelchisari
Study the abstract stuff. You'll never use it, until you do.

------
atemerev
"Don't worry you'll never reach the superstar level. There's always time and
space for improvement".

Still not a superstar, but my code became better in the last 4 years.

------
koolba
I wish I knew about FOSS earlier. After becoming involved in a number of
projects I had the happy realization that there are many smart/crazy/fun
people just like me.

------
d1ffuz0r
Don't try to learn everything. Take 2-3 main areas and become an expert in
these areas. Then keep revisiting every 2 years what you wanna be an expert
in.

------
beaconstudios
build it to work first, then refactor the code to be pleasant. You often learn
so much about the problem while getting even a rudimentary spaghetti code
implementation working that you couldn't possibly have designed a
comprehensive set of objects/interfaces up front, so get it running first,
take what you learned about the problem and update the code to be readable and
well-designed.

~~~
imhoguy
Yeah. Do spike but don't show it to management before minimal cleanup
refactoring! They may think it is done.

------
tapatio
You have to switch companies to get a large pay bump.

------
scalatohaskell
one of most important:

\- get a mentor. Some chilled senior guy with lots of experience. Speak to him
regularly to fish for knowledge. But don't get hung up on everything s/he
says. Programming is huge field with lots of parts.

others:

\- there is no silver bullet

\- simple is not easy (search Simple Made Easy by Rich Hickey)

\- always be pragmatic

\- there are indeed better approaches than OOP, which differ greatly in long
run of project, and pay back (FP) later, and it matters

\- avoid "the chase" of latest best-good thing, get productive in something
that matures well

\- don't ignore latest practices and latest progress just because of the above
mentioned things. Keep learning and try to reapply new stuff (at least in your
head) to range of problems you solved, and think if pro-s and con-s.

\- avoid any heated discussions about languages

\- keep your ego out of work

\- the less you need to code, the better. You are paid to solve problems, not
to churn code.

\- finished is better than perfect. Don't gold plate your solution. On flip
side, don't code shit and try to excuse it with above-mentioned sentence. Be
pragmatic.

\- types are your friends (and friends of your colleagues that have to work
with your code), take time to learn how to leverage them

\- unless you're working on life critical software, don't stress (even then
don't, but...). If you feel pressure and stress, work on handling that. There
is no point in being miserable because someone needs ability to put dog face
onto a photo.

\- you'll be programming for a lot more years to come. You may genuinely like
and enjoy it throughout that period, or hate it. If you hate it, it doesn't
mean you're not suited for programming, maybe you're not using language that
suits you or allows you to express yourself clearly. Yes, people say languages
don't matter. From your perspective as programmer, they do (they don't for
business as long as it gets job done etc.).

\- learn new language at least once per 1-2 years. No need to use it, just get
familiar with it, it's design choices, it's public APIs, some internals.
Language creators are generally very smart and you can learn from them a lot.

\- Once you're a bit more senior learn from other (junior) devs. They're the
ones usually chasing latest hot frameworks. They have time for that. Be
appreciative about that, and take your time to listen to what they have to
say, and what excites them, and how it relates to your experiences. It is also
opportunity to grow.

\- Try to contribute to open source projects. Not to build portfolio, github
or whatever. But to give back some of the service. You'll be paid back by
learning a lot.

~~~
coding123
Probably the best concise list of dev to dev advice I've ever seen.

------
wizzerking
The half-life of OS knowledge is only 3 - 4 years. So half your knowledge
about Windows, or Linux is obsolete in 3 - 4 years

------
legohead
Don't become a language elitist. Love all the languages -- there is something
to learn from each...except Objective-C.

------
alecco
"How you do anything is how you do everything".

You don't get to complain if you are part of the problem.

------
pknerd
A few points:

\- Selling skills either by sharing knowledge in form of code or teaching/blog
posts.

\- Learning the fundamentals.

------
saw-lau
Shipping is a Feature. The most important lesson I've learnt without a shadow
of doubt.

------
darose
That you need a lot more than just coding skill to have a successful career in
engineering.

~~~
darose
Also, that you'll need to pretty much completely reinvent yourself every 5
years or so if you want to stay employable. (I.e., need to keep becoming
expert in some new tech specialty.)

------
zamalek
Complexity isn't smart.

------
frobware
If you think you are in for the long haul then please buy a standing desk!

~~~
astrodust
That's just one tool to avoid strain and it's not for everyone.

The important thing is to remember that strain creeps up on you slowly, then
hits hard. You can get away with bad habits for years, but left unchecked one
day you'll find you can't do anything, it all hurts too much.

Don't push yourself. If you find yourself aching a little, address the problem
rather than pushing through it. I know several people that were knocked out of
commission for the better part of a year after a few decades of casual
neglect.

------
yuchi
Discipline: using, creating and sharing (among the team) checklists.

------
rcarmo
Python. I started out with LISP, C/C++ and Perl.

------
95014_refugee
Get. More. Sleep.

------
iamleppert
1\. Use programming and software as a tool to accomplish your goals, and build
a domain expertise in one or more industries.

2\. Pick a programming language and/or ecosystem and stick to it. That's not
to say there isn't power in being a polyglot, but in order to get really good
you need to pick one thing and practice it. It's that simple. That said, do
not brand yourself as any one thing or be too specific. The key is to both
specialize and generalize. You need to be malleable enough as things change,
but at the same time not constantly chasing your tail with the latest thing.
This fine balance comes with experience, as most new technologies and
techniques you will find are the result of someone rediscovering something. I
can't count the number of times I've seen something rebranded as new or
revolutionary that was originally published as a paper in the 50's or 60's.

3\. Own what you do. Don't wait for others to come to you with problems, think
about ways in which you should be improving your software via instrumentation
and closed loop controls. Try to understand the users of your software and
what they really want and need. Sometimes little things and details that are
seemingly unimportant are very important indeed. Software is a way for you to
directly influence and collect information about the world, so you can be
constantly testing your assumptions and refining your model.

4\. Do personal projects. It's the only way to avoid burn-out and to keep
yourself interested. And in many cases, personal projects can shine the light
for you on where to go next or what to do next.

5\. Get good at interviewing others on a team and make yourself part of the
interview process. Real team building is a far more valuable skill in
accomplishing your goals as an engineer than becoming a manager.

6\. Stay close to the tech. At a certain point you may find yourself in a
position where you aren't coding or creating every day. Avoid this at all
costs. It doesn't matter if you have a team, or if you're in an architect
role, or whatever, you should have the code checked out at all times on your
computer, have it working, and be able to contribute at a moment's notice. If
at any time any of this isn't true for you, stop what you're doing right now
and make it true.

7\. Don't be afraid to throw out huge legacy code bases and start over from
scratch. Nature does this all the time; it's called trial by fire. The second
time you do something is always easier than the first and you can really
eliminate a lot of debt for you and your team.

8\. The first time you do something, if its not messy and weird you aren't
trying hard enough or pushing yourself hard enough. The code will be awful.
Don't strive for perfection in the code the first time, if it sticks you and
others will have plenty of time to refactor and make it better later. I've
seen tons of "perfect", unused code that has never seen the light of day again
and its really sad.

9\. Work for a variety of companies, small and large, startups, mid-size, big
tech, and do freelance at various parts of your career. Different size
companies have different goals, needs and problems and it will help you
understand what is applicable to a Google does not matter at all to a startup
or mid-size company.

10\. Work for companies that are actually doing something, preferably new
work, and try to match that to your interests at the time. Avoid places and
people that are toxic and do not have a deep love of technology and do not
identify as "nerd"/"hacker"/"geek" etc (unless you yourself do not identify
this way..)

------
fb03
Unit testing.

~~~
astrodust
Writing testable code. If you don't know how to do this, write your tests
first to force yourself to think about it that way.

------
gcp
Buy AAPL.

------
thomk
You are going to learn cool new things along the way: just remember though,
when you only know how to use a hammer everything looks like a nail. A better
way to think of it is "Do not be clever". Write code in the most obvious
possible way so you and everyone else that looks at it in 6 months can
understand it.

Early on I was always tempted to prove how smart I was by writing very neat
code that nobody could understand because I was using some esoteric library or
a weird pattern that only kind of fit (although it worked). Don't do that. Try
to be very VERY obvious and you'll thank yourself later.

Its easy to over-engineer any project, but I find OOP especially easy to screw
up with outsmarting yourself. You've heard of "spaghetti code"? Well with OOP
the dreaded paradigm is 'ravioli code' which is tiny little classes all over
the f _cking place.

Find a better way.

Another rule of thumb someone told me once is that your classes should not be
longer than about 1 page of text. Now, before I get yelled at, yes, its very
subjective. You could have 100 lines on one page and I could have 30, I get
it. But I think the idea is at least it is _some* point of reference so you
yourself can judge if a class is trying doing too much.

I worked with an "Architecture Astronaut" (see:
[https://www.joelonsoftware.com/2001/04/21/dont-let-
architect...](https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-
astronauts-scare-you/)) one time who was supposed to be giving me a way to
access a flag in the database. Just a simple boolean that let me set something
to, obviously, true or false.

This guy checked in a 200 line class and walked down to my office to teach me
how to use it. Finally I said "can I just set the value manually?" "Sure" he
says, "Just use this function" and he showed me a 3 line function buried in
there somewhere. Last I heard he is still confusing everyone with his overly
complex solutions to simple problems for Ford.

Programing is FUN, but it's also a profession. Don't get too lost in the fun
of the moment. Write clean, obvious code and you'll see that you don't have to
make things complex to have fun. You'll have more fun solving those big
problems now because you made everything nice and neat and clean along the
way.

I'll end on a quote from Blaise Pascal, Winston Churchill or Mark Twain
(depending on how you google it) that I think applies here as well:

"If I had more time I would have written you a short letter, instead I have
written you a long one."

This could be rewritten like this:

"If I had more time I would have refactored you a short class, instead I have
coded you a long one"

Its a comment about editing (obviously). yes, write long classes then delete
all you can to make them simple like I have explained above.

:)

I should make this comment short, but I do not have the time.

------
brango
That chicks love older guys.

------
jackmott
I spent a long time never bothering to master semi-advanced text editor or ide
features. Like really simple stuff like moving forward/back by a word at a
time, deleting a word at a time, hopping to next/prev brace/paren, renaming
globally, doing everything without needing the mouse, multi-select etc.

You can go even deeper and get into deep VIM style skills but there are many
very easy things to learn that let you do stuff so much faster. Whatever
editor your use, learn to use it.

~~~
SimbaOnSteroids
Okay, so as someone who is less than 4 years into programming what are the key
common shortcuts(not they're actual hotkeys just which ones are used the most)
to learn for semi-advanced text editors and IDE's?

EDIT: thanks for the advice guys, I use Jet Brains range of IDE's for school
cause free licensing and I'm using VS for my summer internship. I'll look into
emacs though, thanks for the suggestion!

~~~
jackmott
I've got a few visual studio tips here:
[https://jackmott.github.io/programming/tools/editor/ide/visu...](https://jackmott.github.io/programming/tools/editor/ide/visual/studio/2016/07/01/marginal-
gains.html)

and here:
[https://jackmott.github.io/programming/tools/editor/ide/visu...](https://jackmott.github.io/programming/tools/editor/ide/visual/studio/2016/07/11/decruft-
visual-studio.html)

I'm not familiar with jetbrains but if you can probably find equivalents for
all those VS tips in jetbrains.

are you one of my interns? haha.

It can be worthwhile to at least partially master emacs/vim as well, since
these exist on all platforms, can be very powerful, can use them when remoted
into a tiny linux cloud box via a terminal, etc etc.

~~~
SimbaOnSteroids
Thanks for the links! Gunna have to check those out today. I've heard that
many of the hot keys in VS are very similar to the ones used by JetBrains.

------
bbcbasic
Work for profitable companies. The company that can barely afford you won't
give good pay raises and will have lousy practices borne from the need to make
ends meet at any cost to technical debt.

Also some aspect of your job will always suck. Even if you find the perfect
job the manager can change or even company gets taken over. For control you
need to run your own biz.

------
praneshp
1\. Learn gdb/pdb/whatever. With IDEs, it's even easier to set breakpoints,
etc.

2\. Try to setup a nice workflow in the early stages. To me, this includes
setting up the code in git, and a minimal test/deploy system. This encourages
me to commit often, make incremental changes, and rollback/switch branches
frequently.

------
killin_dan
Python is going to fuck shit up like you wouldn't believe. Jump ship asap

