HN Explorer

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

102 points by nemild ↗ HN
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.

87 comments

[ 242 ms ] story [ 2317 ms ] thread
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.

niftylettuce
don't go for too many weeks without a vacation, it is detrimental.
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.
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-Coder-Conduct-Professional-Prog...

- Test Driven Development by Kent Beck https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/...

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.
yn37
Yes, yes and yes.

It's funny because technically, none of these three things are part of an engineer's job.

But once you do them, you start noticing how you eventually get to: - save yourself time - save your customer money - avoid unnecessary complications down the road - offer useful comments / feedback / critiques / alternatives, when need be (because you better understand the decisions made around you) - help your customer or team better understand what they really want - find yourself in a better position to transition to other roles, if you choose to

Btw, I wrote a blog article a few days ago about exactly this: http://claudiu.dragulin.com/2016/12/02/dont-just-code-solve-...

cwisecarver
This: most user stories / user requests are raw diamonds waiting to be polished. ("What do they really want me to solve")
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.

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.
debt
i'd ask younger me

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

wtetzner
Surround yourself with people smarter than you. It's the best way I've found to improve quickly.
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.
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.

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

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.

ajeet_dhaliwal
Well at least understand it's not the be all and end all.
IWillScoop
I've had OOP driven into me since I started learning programming, what would you recommend instead?
[deleted]
(comment deleted)
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.

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.
techscruggs
It is a team sport. Learn to recognize when to ask for help and who is the best suited to help you.
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.
[deleted]
(comment deleted)
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.
[deleted]
(comment deleted)
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
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
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).