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.
* 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.
> * 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.
* 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.
> 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.
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.
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).
- 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")
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.
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.
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
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!
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.
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.
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.
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.
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.
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...
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.
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.
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.
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
> * 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'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.
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.
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.
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.
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.
* 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.
* 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.
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.
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.
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 !
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.
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.
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.
* 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