
Ask HN: Senior developers, what would you tell a younger you? - nemild
I’m specifically interested in what you’d tell someone to help them develop a senior engineer mindset. And when I use the word “senior” I don’t mean title or age, but the engineering maturity that it implies.
======
rckclmbr
* Don't strive to be a senior engineer. Strive to solve peoples problems through technology

* Always be solving problems

* Make mistakes, and learn from them

* Just because something didn't work 5 years ago doesnt mean it wont today

* Don't buy into hype

* Be passionate and excited about things. You're not a robot

* Don't feel guilty about wasting time.

* Don't overabstract every problem

* The quickest solution is generally the best solution -- or at least help you understand the problem better. Don't design a large solution to a problem, solve lots of smaller problems.

* Do things that align with your strengths

* Know what your strengths are

* Build relationships with people. Be their friends. Talk to them about non- work related things

* Keep meetings to 30 minutes. Always have a takeaway from a meeting

* Have a life outside of work

* Set goals for yourself. Set goals higher than you think you can achieve. Make a plan for achieving the goal.

* Hold yourself accountable

* Don't be an ass

~~~
patrickgordon
> * Build relationships with people. Be their friends. Talk to them about non-
> work related things

Making friends and socialising is not something that comes easily to me so
this is something I have been actively working on for the last year and it has
had a profoundly positive effect on my work-life.

I am still amazed at how much more willing people are to go out of their way
to help me work-wise when we have even a small(?) personal relationship.

------
GrinningFool
* Some people will be hostile to you or your ideas. Maybe it will be personal, maybe not - but people can be ass-hats, so expect it. Don't waste a lot of energy on people who have no interest in exploring new ideas simply because they didn't come up with them.

* there's always something to learn. You know that, but you'll lose sight of it.

* look at the bigger picture, always

* don't be afraid to ask questions, as many as you need until you have the information you need.

* worry less about what you want, and more about doing the right thing for the customers you're building for. (In the end, there's a surprising amount of overlap...)

* 12 hour days might feel good, but they don't help in the longer term.

* you can't do it all yourself.

* you'll get paid more than you need to survive - so don't be an idiot with your money.

* talk to people. continue to talk to them after you are no longer required to interact with them regularly. Relationships are work, but they're important to your sanity and career.

* Those things you avoid because they're too hard? They're not really too hard, and that's not really what's stopping you. There's nothing wrong with failing.

* Those ideas you have? Do something with them. But one at a time, and make an active choice as to whether it's worth finishing.

* There will always be things that you want to do better. Don't let that stop you from shipping.

* Don't read comments. And for the love of FSM, don't reply to them.

~~~
typicalrunt
Hmm, I'm replying to a comment... Oh well. :)

> you'll get paid more than you need to survive - so don't be an idiot with
> your money.

Adding to this is something to consider:

You will be paid more than you need to survive, but you will most likely
survive longer than you will be paid. Make sure you save money for those
times.

~~~
GrinningFool
Very valid point, also a thing I figured out nearly (but hopefully not) too
late.

------
falcolas
See that Senior Engineer over there with the white hair, dorky glasses and a
shirt begging for a pocket protector? Attach yourself to him and listen.
You'll learn more from him in ten minutes than you will in ten hours of
conversation with your classmates-cum-coworkers.

That knowledge will build up with time, and someday, a younger developer will
come to you with questions. Take the time and answer them; it's worth it.

------
misiti3780
* If you look around and your the best person on the team, start looking for another job -- it will be a lot harder to get better if you dont.

* Switch employers every 2 years. Do not have loyalty unless you have stock options.

* Contribute to open source for the learning experience

* Use what works, dont focus on the hot new trends (redis, mysql, django, ror vs express, mongodb, etc.).

* learn at least one functional language really well

* learn one statically typed language really well

* learn one dynamically typed language really well

* multiply all time estimates by some coefficient C, where C is always larger than 1.

* become familiar design patterns described in Gang of Four

* learn the UNIX commands and piping really well, they will save you a lot of time.

* have side projects and dont be scared to show them off!

~~~
jnbiche
> * Use what works, dont focus on the hot new trends (redis, mysql, django,
> ror vs express, mongodb, etc.).

You consider mysql, django, and ror as "hot new trends"? What databases
systems and web frameworks do you consider not to be "hot new trends"?

I first used mysql 15 years ago, and it was already an established project at
that point.

~~~
misiti3780
no, im saying express, mongodb, etc. edis, mysql, django are new are
established

------
dmistrio
Thou shall not work in a company where there is no career path/1o1s/generally
good management. In the interview ask how to verify what is being offered.
Thou shall not never ever work overtime unless it is clearly appreciated
and/or compensated.

------
itamarst
1\. Negotiate for your salary. Once got an offer I accepted which turned out
to be (at least) 20% below what company was willing to pay me if only I'd
asked.

2\. Always test your code, and if you're writing in language you're new with
get someone else to code review it. Especially if you're bugs are likely to
break your company's main customer.

3\. Technology is worthless if it doesn't help you achieve your goals.
Software is worthless if it doesn't help you achieve your goals. Figure out
your goals first.

4\. Put another way, ask "why", don't just code.

(These are all based on actual mistakes I've made. You can get the full story
of these and other mistakes I've made at
[https://softwareclown.com](https://softwareclown.com)).

------
data_hope
\- don't only worry about code or getting features shipped, but about the
process, how to deliver quality.

\- behind any given reason, there is a complex network of real reasons. You
don't need to second-guess any decision/order/suggestion, but it helps
understanding.

\- most user stories / user requests are raw diamonds waiting to be polished.
("What do they really want me to solve")

Essential reading list:

\- Clean Coder and Clean Code [https://www.amazon.com/Clean-Code-Handbook-
Software-Craftsma...](https://www.amazon.com/Clean-Code-Handbook-Software-
Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&qid=1481652641&sr=8-1&keywords=clean+code)
[https://www.amazon.com/Clean-Coder-Conduct-Professional-
Prog...](https://www.amazon.com/Clean-Coder-Conduct-Professional-
Programmers/dp/0137081073/ref=sr_1_2?ie=UTF8&qid=1481652641&sr=8-2&keywords=clean+code)

\- Test Driven Development by Kent Beck [https://www.amazon.com/Test-Driven-
Development-Kent-Beck/dp/...](https://www.amazon.com/Test-Driven-Development-
Kent-
Beck/dp/0321146530/ref=sr_1_1?ie=UTF8&qid=1481652707&sr=8-1&keywords=test+kent+beck)

~~~
Sumaso
I really didn't enjoy the clean coder. There was a strong feeling of
"Management is trying to screw you over, this is how to protect yourself from
them". If your really working in that environment, you should probably just
leave rather than having to resort to tricks and techniques to manage
management. There seemed to be some other silly advice (I.E. I used to listen
to music and code until 4AM and then not remember what I wrote. Clearly the
music was to blame.)

I'm sure that Rob is a great employee, and the book does have a few good
points, but I'm not sure I took away a whole lot from it.

~~~
data_hope
interesting, reading your comment, I would never guess that we are speaking
about the same book. I found it to be more of a guidebook to precise
communication with colleagues and management.

------
briHass
New frameworks/tools/libraries are fun and cool, but wait until it has
widespread adoption before choosing it for a large project. It's OK to be a
late adopter of new technologies.

------
mercer
I don't consider myself a senior developer, but this is what I'd tell my
younger self:

\- don't spend to much time on exploring tools, but whenever you notice you're
repeating yourself often, make sure to do a quick search to see if there's a
quicker way. There usually is, because others will repeat themselves in
similar ways.

\- make sure to find _real_ projects (where you get paid or at least dinged
for not delivering) that offer a degree of challenge/unfamiliarity. I've gone
months with very little progress in my abilities, only to take on a project
with an unfamiliar toolset or environment and learn a shit-ton of stuff that
helped my long-term.

\- find a mentor!

\- look into this 'functional programming' thing, but don't become a convert.
It's not the solution to everything.

\- if the coding you do for work doesn't excite you, make sure to find some
exciting side-project. Programming, at least for me, is _so_ much fun. I've
let work take the fun out more than once, to the point where I'm seriously
considering finding some other line of work to make a living so I can code
_just_ for fun. 'Unfortunately' my front-end work is so lucrative that it's
the best way to have as much free time as possible.

And the two biggest ones:

\- _" Bad programmers worry about the code. Good programmers worry about data
structures and their relationships." and "Show me your flowchart and conceal
your tables, and I shall continue to be mystified. Show me your tables, and I
won't usually need your flowchart; it'll be obvious."_ I can't properly
express how much this has improved my coding. I don't think it's a coincidence
that React/Redux (often) put such an emphasis on one big state object to work
with. If I start my work with thinking about the data structures and their
relationship, the code becomes so much easier to write!

\- Watch 'Simple Made Easy'.

------
strictnein
Every single popular framework/language/tech will be less so one day. Don't
get too hung up on any individual one, or focus your career on a small subset
of them.

------
pjmlp
\- Soft skills are as important or even more than than technical ones;

\- Always judge the business value of any change request

\- Be weary of any technology that promises to revolutionise the world of
programming

\- Get to know the whole stack, even if only in abstract terms, don't focus on
silos

\- Care about the business side, how the technology meets the needs of the
actual users and way of doing business

\- Never ever sacrifice private life for the employer. They won't think a
second about your sacrifices when showing the door to teams

------
rufius
Getting quickly to my position would be a frustrating proposition. A
considerable portion of how I got where I am is because of the mistakes I
made. I wouldn't want to have gotten here faster and the pursuit of getting to
"senior" faster isn't the right mindset.

The goal should be continual improvement which includes successes and
mistakes. Preferably, these are done at a pace that lets you enjoy your youth,
family, friends, and life.

~~~
nemild
Thanks, I modified the question to be more clear.

I often find that mistakes other make are valuable for me to learn from as
well. I could make every one of these mistakes serially as well, but in some
cases, learning from those of others is a good enough lesson for me.

------
Harimwakairi
Your success in delivering great software will depend as much on your ability
to work with people as it will the technical skills you so carefully husband.

~~~
swalsh
I would second this point, and add these skills can be learned. Here's a great
book: [https://www.amazon.com/How-Win-Friends-Influence-
People/dp/0...](https://www.amazon.com/How-Win-Friends-Influence-
People/dp/0671027034)

------
matthewrudy
* choose work for the people, not the money

* always be learning, but focus on architecture and design, not implementation specifics

* work hard, but make sure you don't forget to live

* always do a good job, never burn any bridges, and in 10 years things will be great

------
pesfandiar
It doesn't have to be perfect. It just has to make sense for the business,
even if it means skipping things that you deem necessary for a perfectly-
engineered product.

Also, be open to tasks that are not just hands-on coding. Tasks related to
testing, documentation, mentoring, product management, project management,
etc. add value to the business and make you a more valuable and versatile
player.

------
0xcafecafe
Keep learning, surround yourself with smarter people than you, find a good
mentor/s, ditch your ego, don't be afraid to be wrong and don't hesitate to
throw away your code if needed.

------
gt565k
Deliver, deliver, and deliver some more.

And by that I mean be involved in projects from start to finish.

If you find yourself at a company for more than 2 years, and you've only
worked on 1 boring project, it's time to look for new opportunities. Now,
there could be multiple small projects as part of one big one, that's
different, as long as it provides you value and helps you progress in your
career.

The only way to progress as a software engineer and get a solid understanding
of the SDLC[0] is to keep cranking out projects from start to finish.

There are far too many people that get stuck maintaining a project right out
of college, and never experience the full SDLC.

The more projects you deliver from scratch, the better you'll be at estimating
tasks, understanding risk, business priorities, etc...

[0]
[https://en.wikipedia.org/wiki/Systems_development_life_cycle](https://en.wikipedia.org/wiki/Systems_development_life_cycle)

------
psyc
Don't spend so much time coasting in jobs you're not really interested in,
because you think it's the best you can do, and it pays well. The years go by
fast. Be dogged about building skills in areas of real interest, getting into
that sector, and meeting people who are focused on similar things.

------
wtetzner
Surround yourself with people smarter than you. It's the best way I've found
to improve quickly.

------
elliottcarlson
Don't let imposter syndrome hold you back - it's not bad to check yourself,
and imposter syndrome can certainly help you as well - but when it prevents
you from even trying to get ahead, it can delay your career trajectory
significantly. Be confident in what you do know.

~~~
fjrieiekd
This is a good one -- I think there's a point after a few years where one
realizes just how little they actually know, even if they are otherwise quite
proficient. It's ok to not be the smartest guy in the room or have the ability
to come up with your own algorithms, compilers, etc...

keep on learning and make use of what you learned, and don't be afraid to be
less than perfect and make mistakes.

------
pryelluw
Focus more on people skills. Took me too long to figure that one out. :)

~~~
jobu
Always be working on the "soft skills" (people skills, communication skills,
writing, etc.) The "hard skills" may come easy for you, but they will only
take you so far in life.

------
jressey
In the latter part of my career, I have focused more on mental health,
happiness, and early retirement. The things below reflect that more than how
to become 'great' or whatever.

* Remember that people with non-software skills are probably just as smart and hardworking as you are

* No matter how much more qualified you are than your coworkers, don't fight every battle even if they are always wrong

* Actually read (don't skim) documentation and source code

* After you have some money saved up, quit your job and look for your dream job full-time

* You'll be perfectly happy having never worked in Silicon Valley, or for any prestigious companies

* Read error messages and understand instead of just googling

* Switch mentors often

* Forget about getting rich

~~~
mywittyname
> * Remember that people with non-software skills are probably just as smart
> and hardworking as you are

And maybe/probably smarter.

One of the smartest people I ever worked with was a _sales guy_ (gasp). The
dude could spend 3 minutes listening to you explain something, instantly grasp
the problem, have an idea of what the solution would look like, then
communicate that to the customer in a way that made it look like we were doing
them a huge favor. He had a non-technical degree and his background before
joining our company was at a car dealership.

He once declared himself Master Lord Architect of All Things Technical after
he figured out an issue to a problem in the span of a conversation that took
three engineers the better part of a week.

I did not object.

------
joemanaco
Don’t ever bother learning or using object-oriented programming.

~~~
Chos89
Care to explain?

~~~
joemanaco
I've wasted many, many years thinking OOP is the right way to do things and
just realized in 99% it's the wrong approach to develop software. In the end
you always end up in a big mess of classes, dependencies. And every now and
then new there are new best-practices, design patterns or solutions to fix the
problems only to make it even more complex.

Please watch this video. I don't agree 100% but with most of it:
[https://www.youtube.com/watch?v=QM1iUe6IofM](https://www.youtube.com/watch?v=QM1iUe6IofM)

~~~
Shorel
I learned that lesson with the transition from WordPerfect 5.1 to WP 6.0.

The new Object Oriented WP 6.0 macro language was unable to do the things I
did with the 5.1 macro language (a typewriter mode for diacritics plus spell
checker plus smart commas and smart spaces).

Since then, I have always been an skeptic about OOP.

Also: closures are not too different to instantiated objects, one can usually
convert from one style to the other while keeping all functionality.

------
dwc
There are so many things, of course. But here are two things I wish I'd
understood better a long time ago:

* Think in the problem space / avoid thinking in implementation details. Structure your solution along lines that make sense in the problem space, name variables for that, etc.

* Do the simplest thing that solves the problem at hand, but no simpler. Small, simple implementations are easier to change when (not _if_ , _when_ ) unanticipated changes come up. If you anticipate additional functionality, leave the door open to those changes rather than writing code for them now.

------
techscruggs
It is a team sport. Learn to recognize when to ask for help and who is the
best suited to help you.

------
niftylettuce
don't go for too many weeks without a vacation, it is detrimental.

------
atarian
1\. Be very careful around people who are charismatic; make sure their actions
correlate with the things they say.

2\. Your manager can make or break your career. If you have a bad manager, you
need to get out or you will always be disappointed when it's time for
promotions and raises.

3\. Soft skills matter way more than the hard ones. You don't have to be a
good public speaker, but you need to know how to navigate difficult
situations.

------
AnimalMuppet
There are toxic work environments. When you're in one, start looking and move
to the first good alternative. Don't stay in something that's become a pit.

On the other hand, if you have a good situation (realistic management, decent
pay, good co-workers), think very carefully before moving. Such situations are
not all that common.

------
dano
* If you find yourself doing maintenance work, move to a new job

* Study new things 8 hours per week

* You are not the R&D department for the next cool thing, use established tech to build your own cutting edge product.

* Take stock in lieu of salary and go all-in

* Focus on reduced cycle time for development; e.g., develop against small representative datasets

* Learn new programming languages regularly; i.e., don't be a C# expert without also knowing python, R, scala, perl, Go, etc..

* Relationships are very important, learn to be social, it isn't always easy

* Learn to ask questions rather than make statements with your team members

* Never make things personal or question people into a corner, the goal is larger than the current issue

* Long-term employment in technology isn't. You really need to try out new companies from time to time and challenge yourself.

* Be a servant leader to everyone around you.

* Mind dependencies, resolving constraints gives you immediate freedom and accelerates progress

ps: great thread.

------
cwisecarver
* Learn how to learn.

* Admit when you don't know something and then rectify it (if it's interesting to you).

* A stable solution is better than the bleeding-edge solution.

* Smaller (simpler) is better. (KISS)

* Learn how to gauge technical ability in a conversation with someone and compensate for that on the fly. Non-techies will love you.

* 80hr weeks will not make the company love you. They will only make everyone else in your life dislike you. And eventually, the people at the company.

* Shop around. You don't have to take the job offers but keep interviewing. You learn as much about yourself as they learn about you.

* Find a problem-space you love and develop it. Tech is tech but business is business. Finding an area that you like to solve tech problems in will make you happy.

* Don't make technical arguments personal. Make your point, with facts, let them make theirs. Agree if you're wrong.

------
hbt
* Get it to work first. Make it pretty later.

* Don't waste time & energy learning trendy tech. Hold your excitement and ask yourself: "what can I do with it that I can't do with my existing arsenal and is it worth the ROI?"

* Learn to identify companies that are nothing more than feature factories

* Ownership is better than a paycheque. It means control over your decisions and work quality.

* When working at corp/consulting, focus on the things you can control and the people you can influence. The rest is out of your hands and not worth the emotional investment.

* Learn to let go. Tech gets out of date. Software you spent years working on gets replaced. Stuff stops working because of dependencies down the line. Nothing lasts forever.

* Focus on getting better and investing in yourself.

------
mysterydip
Don't optimize too early, no matter how bad the itch (or clever your
solution). Chances are that part could change and your optimization could have
implications elsewhere or on features not yet added

------
dmvaldman
It's as important to know the costs as it is the benefits of some technology.

Know programming patterns. Be able to categorize a problem as an instance of a
pattern (or not).

Know what you don't know.

Execute.

Being better at debugging is more valuable than coding faster.

Train those junior to you as if you want them to replace you.

Use the Socratic method. Ask a lot of questions. Over-communicate.

Be able to adapt yourself to the person you're talking to.

Be able to manage "up." People should trust you not only because you can get
things done, but also because they are well informed that things are getting
done the way they want.

------
grayrest
What makes someone a senior developer is that they reliably reduce technical
risk to a project and deliver on time. There are a lot of definitions for
"senior" floating around, but that's what everybody really wants.

The main advice I give to junior developers is that state is the core of
incidental complexity. Focusing on minimizing state to the degree practical is
the simplest trick I know for producing well designed systems. The only place
it doesn't necessarily work is high performance code.

------
shortoncash
Avoid the desire to do a rewrite. Knowledge is baked into the existing code
that you could be tossing away for no reason. If things are reasonably
encapsulated, there is absolutely no reason to rewrite everything.

I cringe when developers call for a rewrite. It's a massive red flag to me
that they aren't team players and will be lazy. They won't take the time to
read or understand things. Rewrite calls make more sense after they have read
the code in the first place to being with.

------
heldrida
you'll stress less and make way more money has a tattoo artist

------
partisan
Try a lot of different technologies even if you will never use them. Read
other peoples' code. Be open to using other libraries. Not invented here is a
failing mindset.

------
vcool07
* Get a post-graduate (Masters) degree - either MS or MBA, within the first four years of employment.

* Work hard and earn/learn as much as you can in the first 10 years of job. Volunteer for code reviews, take up jobs outside your comfort zone, build a solid network of peers. IMO, what is learnt in the first 10 years is gonna stick with you for the rest of your career, so be a sponge and absorb as much as you can in this time !

------
mtberatwork
Don't go to work for that burnout factory (large consulting company) just
because it looked good on the resume. 12 hour days aren't worth it.

------
tmaly
* company culture is important

* take risks, work for a company that wants to change the world

* contribute to open source

* code is read more than it is written, learn to write code that is easy to grok

------
sirwolfgang
\- Focus on solving problems not writing code. Many problems can be solved
with a communication, long before you need to write a line of code.

------
ereyes01
\- Go out and have a little more fun on the weekends.

\- Stop underestimating problems, assume they are hard until you can prove
they are easy.

\- The squeaky wheel gets the oil. Doing great work that no one knows about
doesn't get you recognized, and doesn't help anyone.

\- Trust your own intuition and insight more. They are often correct about
other people and your own life direction, but get ignored too often.

------
paulmooreparks
* The technical decisions you make today will haunt you, or your replacement, for the next 20 years.

* Don't fall for the line, "We'll fix it later." It will never be "later," and the problems will never be fixed. Do it now, while it's cheaper.

------
rbrcurtis
You will learn far more and work on more interesting things by doing side
projects than you generally ever will at work. This will result in having a
better resume and getting more interesting jobs as a result.

------
tyingq
If you have a family, strongly consider future you when you think about work-
life balance decisions.

I would gladly have traded off some of my career success for more family
time...had I known then what I know now.

~~~
AnimalMuppet
And be more mentally and emotionally present while at home.

------
mooreds
Take risks now!

I took some risks and enjoyed my 20s and early 30s immensely, but also played
it pretty safe. I would advise my younger self to take more risks,
specifically around creating products.

------
babyrainbow
For god's sake, don't pick up that Php job.....

------
swalsh
Become an expert in at least 1 or more non-technology related things. Whether
it be a certain industry or a "non-technical" skill.

------
LeonidBugaev
* Learn to be a better writer from start

* People are more important than code

* Don't fall in love with specific technology

* Do not rush, force yourself to slow down

------
debt
i'd ask younger me

"do you want to work long hours sitting at a computer everyday until you're
dead?"

------
salarycommenter
Most senior people I know are under paid and over worked. The lucky ones are
just under paid.

------
brazzledazzle
* It doesn't matter how good your work is, it only matters what your boss thinks.

------
pbh101
Seek out and deliver value. Know why and how what you're building is valuable.

------
anpk
Dont worry about the small things or the latest technology, it doesn't matter

------
patrickdavey
Never ever stop learning.

------
loader
When you're done building it, spend the time to market it.

------
JoeAltmaier
Communicate consistently.

------
NotThe1Pct
DO NOT TALK TO RECRUITERS.

They hate you because you have skills and they usually failed in their careers
(or have a liberal arts degree, which is even worse).

They will record and make public whatever you told in private.

They will blanket spam your CV to every corner of the world.

They will lie to you to make you sign it.

They will make you feel worthless so you can accept a lower package.

~~~
teekno
As a software engineer, I would argue that my liberal arts education is one of
my greatest assets.

~~~
NotThe1Pct
I find that refreshing. But for 50% of liberal arts majors, under and
unemployment is a hard reality.

[http://www.theatlantic.com/business/archive/2012/04/53-of-
re...](http://www.theatlantic.com/business/archive/2012/04/53-of-recent-
college-grads-are-jobless-or-underemployed-how/256237/)

The problem is not intrinsically the content of the degrees but the fact that
there is probably 2x as much graduates being thrown in the market than there
are jobs.

------
sickbeard
* Crush your enemies, see them driven before you, and hear the lamentations of their women

