Ask HN: Senior developers, what would you tell a younger you?
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
* 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
* 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
> * 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.
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.
* 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.
* 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.
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.
> 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.
Very valid point, also a thing I figured out nearly (but hopefully not) too late.
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.
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.
* 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!
* 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!
> * 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.
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.
no, im saying express, mongodb, etc. edis, mysql, django are new are established
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.
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).
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).
- 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/...
- 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/...
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.
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.
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.
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-...
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-...
This: most user stories / user requests are raw diamonds waiting to be polished. ("What do they really want me to solve")
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.
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'.
- 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'.
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.
- 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
- 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
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.
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.
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.
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.
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.
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...
* 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
* 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
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.
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.
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.
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
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
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.
Surround yourself with people smarter than you. It's the best way I've found to improve quickly.
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.
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.
keep on learning and make use of what you learned, and don't be afraid to be less than perfect and make mistakes.
Focus more on people skills. Took me too long to figure that one out. :)
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.
Same
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
* 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
> * 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.
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.
Don’t ever bother learning or using object-oriented programming.
Well at least understand it's not the be all and end all.
Care to explain?
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
Please watch this video. I don't agree 100% but with most of it: https://www.youtube.com/watch?v=QM1iUe6IofM
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.
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.
I've had OOP driven into me since I started learning programming, what would you recommend instead?
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.
* 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.
It is a team sport. Learn to recognize when to ask for help and who is the best suited to help you.
don't go for too many weeks without a vacation, it is detrimental.
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.
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.
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.
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.
* 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.
* 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.
* 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.
* 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.
* 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.
* 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.
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
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.
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.
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.
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.
[deleted]
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.
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.
you'll stress less and make way more money has a tattoo artist
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.
* 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 !
* 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 !
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.
* 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
* 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
- 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.
- 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.
- 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.
* 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.
* 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.
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.
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.
I would gladly have traded off some of my career success for more family time...had I known then what I know now.
And be more mentally and emotionally present while at home.
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.
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.
For god's sake, don't pick up that Php job.....
Become an expert in at least 1 or more non-technology related things. Whether it be a certain industry or a "non-technical" skill.
[deleted]
* 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
* People are more important than code
* Don't fall in love with specific technology
* Do not rush, force yourself to slow down
i'd ask younger me
"do you want to work long hours sitting at a computer everyday until you're dead?"
"do you want to work long hours sitting at a computer everyday until you're dead?"
Most senior people I know are under paid and over worked. The lucky ones are just under paid.
* It doesn't matter how good your work is, it only matters what your boss thinks.
Seek out and deliver value. Know why and how what you're building is valuable.
Dont worry about the small things or the latest technology, it doesn't matter
Never ever stop learning.
When you're done building it, spend the time to market it.
Communicate consistently.
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.
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.
As a software engineer, I would argue that my liberal arts education is one of my greatest assets.
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...
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.
http://www.theatlantic.com/business/archive/2012/04/53-of-re...
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.
* Crush your enemies, see them driven before you, and hear the lamentations of their women
[deleted]