Veteran engineers (10 yrs exp+) advice needed
In hindsight what were the best career moves you made that really leveled you up as an engineer (i.e made you a much better engineer).
43 comments
I have called myself “programmer” for 40+ years, never “engineer.” I worked as an employee in cubicle farms for over 20 years, then freelanced full-time for about 15 years as I aged out of the cool startup/FAANG scene.
Since you asked about career moves, the best things I did:
- Learned relational databases and SQL in depth. Many applications (and almost all business applications) are built around databases. Databases tend to have more business value and longer lifespans than application code.
- Learned Unix/Linux and the command line tools. I can get a lot done with simple stable tools that come out of the box when other “engineers” are writing piles of code to get the same job done.
- Get along with other people, learn from them, listen and pay attention. I always want to learn how the business works and what people who aren’t programmers do. That pays off in the form of contacts in various industries and positions who may give me work later. Connections count for a lot, more than languages and tools (now called “stacks”) in my experience.
- Domain expertise. Rather than think of myself as a “C programmer” or “PHP programmer” I present myself as someone who can understand business requirements and add value. Knowing how logistics or retail or finance works has more long-term career value than mastering a programming language.
Since you asked about career moves, the best things I did:
- Learned relational databases and SQL in depth. Many applications (and almost all business applications) are built around databases. Databases tend to have more business value and longer lifespans than application code.
- Learned Unix/Linux and the command line tools. I can get a lot done with simple stable tools that come out of the box when other “engineers” are writing piles of code to get the same job done.
- Get along with other people, learn from them, listen and pay attention. I always want to learn how the business works and what people who aren’t programmers do. That pays off in the form of contacts in various industries and positions who may give me work later. Connections count for a lot, more than languages and tools (now called “stacks”) in my experience.
- Domain expertise. Rather than think of myself as a “C programmer” or “PHP programmer” I present myself as someone who can understand business requirements and add value. Knowing how logistics or retail or finance works has more long-term career value than mastering a programming language.
20+ Years of dev, some of these I did right, some I wish I did ;)
1-Learn one language/stack inside out. That knowledge translates very well o other stacks: They need to solve the same problems, they just have different approaches/solutions.
2-Don't be a fanboy of one stack: Work with others, if you are a backend developer, do some frontend, if you work with strongly typed languages, try python for some time, if you have always used GC languages, try rust, etc. Different languages/stacks teach you different ways to come up with solutions.
3-This one is suggested by the others, but it cannot be overemphasized: Learn SQL, and learn it well. Postgres (with all its gotchas) is an incredible work of engineering, learn that and you can easily switch to others when needed.
4-Take care of your body. Find the exercise that works well for you. I hate gym, but love tennis.
5-Take care of your mind. Avoid people and workplaces that waste your mental energy. The world is packed with awesome people and companies to discover.
6-Be reasonably kind to people. They tend to re-appear later in your life and play roles you would not imagine now. But be kind and forget (as in fire and forget): don't expect people to return your kindness, this expectation leads to disappointment. Also, don't make your plans based on that.
7-Push your limits. This is not overworking. Learning for 1 hour/day for years can make a huge difference. But also be ready to finish a book on a weekend and come back next week with some firm understanding of a concept/technique/tool... if that's needed.
1-Learn one language/stack inside out. That knowledge translates very well o other stacks: They need to solve the same problems, they just have different approaches/solutions.
2-Don't be a fanboy of one stack: Work with others, if you are a backend developer, do some frontend, if you work with strongly typed languages, try python for some time, if you have always used GC languages, try rust, etc. Different languages/stacks teach you different ways to come up with solutions.
3-This one is suggested by the others, but it cannot be overemphasized: Learn SQL, and learn it well. Postgres (with all its gotchas) is an incredible work of engineering, learn that and you can easily switch to others when needed.
4-Take care of your body. Find the exercise that works well for you. I hate gym, but love tennis.
5-Take care of your mind. Avoid people and workplaces that waste your mental energy. The world is packed with awesome people and companies to discover.
6-Be reasonably kind to people. They tend to re-appear later in your life and play roles you would not imagine now. But be kind and forget (as in fire and forget): don't expect people to return your kindness, this expectation leads to disappointment. Also, don't make your plans based on that.
7-Push your limits. This is not overworking. Learning for 1 hour/day for years can make a huge difference. But also be ready to finish a book on a weekend and come back next week with some firm understanding of a concept/technique/tool... if that's needed.
To add, 1+2 is often referred to as being a "T-shaped developer"
These are all gleaned from mistakes I've made or seen made in my career:
. Don't do a good job; only seek to make sure ppl (managers and co-workers) are happy with the job you do.
. Do what's best for you (not necessarily the organization). Aka Resume Oriented Architecture. Aka ROA for the best ROI.
. View being employed as a business. Would you ever start a business to sell to one client? Always be looking for the next client.
. Never document anything. Sadly, the more obscure language/tech/code/artefact you emit, the harder it is to get rid of you. I inherited a whole team that had all the router/switch/etc passwords in their heads "for security reasons". They could not be fired, even for coming in at 10.30am and leaving at 3.30pm, constantly missing meetings, etc.
. Hire someone to replace you once you've built an inscrutable system. You can't get promoted if you still do everything and you can't do nothing (manage) if there are things to do.
. Save and invest often. If you do, by the time someone competent is in a position to see how bad a job you did and bring the hammer down on you, you'll have enough to take up woodworking and occasionally chuckle to yourself thinking about how anyone would ever right the trail of destruction you've left.
. Never tell anyone these things. ;>
/sarcasm
. Don't do a good job; only seek to make sure ppl (managers and co-workers) are happy with the job you do.
. Do what's best for you (not necessarily the organization). Aka Resume Oriented Architecture. Aka ROA for the best ROI.
. View being employed as a business. Would you ever start a business to sell to one client? Always be looking for the next client.
. Never document anything. Sadly, the more obscure language/tech/code/artefact you emit, the harder it is to get rid of you. I inherited a whole team that had all the router/switch/etc passwords in their heads "for security reasons". They could not be fired, even for coming in at 10.30am and leaving at 3.30pm, constantly missing meetings, etc.
. Hire someone to replace you once you've built an inscrutable system. You can't get promoted if you still do everything and you can't do nothing (manage) if there are things to do.
. Save and invest often. If you do, by the time someone competent is in a position to see how bad a job you did and bring the hammer down on you, you'll have enough to take up woodworking and occasionally chuckle to yourself thinking about how anyone would ever right the trail of destruction you've left.
. Never tell anyone these things. ;>
/sarcasm
I made it more than halfway down thinking you were serious. Sadly there are people who think these things.
You are a mercenary.
* Loyalty does not exist (company, coworkers, etc)
* You dictate pay for the work you do (or leave the job)
* You dictate your own hours (overtime is your own choice not company's)
* Strive to always provide maximum value (efficiency not time spent)
* Focus on keeping a core set of skills sharp
* Quit if conditions are untenable
> Loyalty does not exist (company, coworkers, etc)
I can't quite call myself a veteran engineer yet, but loyalty and positive relationships with coworkers is a huge boon. I agree that companies will often screw you. Manager and policies can change in an instant and they only look out for their self interests.
But coworkers? Find great coworkers that you work well with and you will always have job opportunities. If a coworker jumps ship to another company, it's likely because the pay and benefits are better. Now I have an "in" for a referral plus insight into how the company operates and how I'll get along with the team.
I do agree with all the other points though.
I can't quite call myself a veteran engineer yet, but loyalty and positive relationships with coworkers is a huge boon. I agree that companies will often screw you. Manager and policies can change in an instant and they only look out for their self interests.
But coworkers? Find great coworkers that you work well with and you will always have job opportunities. If a coworker jumps ship to another company, it's likely because the pay and benefits are better. Now I have an "in" for a referral plus insight into how the company operates and how I'll get along with the team.
I do agree with all the other points though.
A network of current and ex-co-workers is valuable. The point I was trying to make was that a person shouldn't stay in a position solely out of a sense of comradery or loyalty to one's co-workers.
For me, leaving the States.
There is an impenetrable glass ceiling in the states based on where you come from, where you went to school, if you can pass made up tests, and if you’re an extrovert.
For example, I’ve always wanted to work in R&D, but it’s impossible in the states. If you don’t have a masters degree from a good school, you can’t even get an interview. And (from my experience) you can’t get a masters degree from a good school unless you’re already rich.
For reasons I won’t bother going into, I’ve been denied getting into any Uni that would allow me to even get a degree that pass any kind of HR filter. Let alone have the personality to pass any needlessly high pressure white board interview.
Almost none of these things have mattered since I left, and I’ve had way more opportunities. Additionally, people in tech, in general, are far less shitty.
I was close to committing suicide in the states, and my life now is amazing (and has been for years).
Depending on the issues you’re facing, your personality, and if you live in the states now, I would highly recommend leaving and trying your hand elsewhere on the globe. Especially if you grew up poor.
(To preempt the “oh you didn’t try hard enough, it’s easy I just did xyz” - good on ya!)
There is an impenetrable glass ceiling in the states based on where you come from, where you went to school, if you can pass made up tests, and if you’re an extrovert.
For example, I’ve always wanted to work in R&D, but it’s impossible in the states. If you don’t have a masters degree from a good school, you can’t even get an interview. And (from my experience) you can’t get a masters degree from a good school unless you’re already rich.
For reasons I won’t bother going into, I’ve been denied getting into any Uni that would allow me to even get a degree that pass any kind of HR filter. Let alone have the personality to pass any needlessly high pressure white board interview.
Almost none of these things have mattered since I left, and I’ve had way more opportunities. Additionally, people in tech, in general, are far less shitty.
I was close to committing suicide in the states, and my life now is amazing (and has been for years).
Depending on the issues you’re facing, your personality, and if you live in the states now, I would highly recommend leaving and trying your hand elsewhere on the globe. Especially if you grew up poor.
(To preempt the “oh you didn’t try hard enough, it’s easy I just did xyz” - good on ya!)
Where did you go?
None. My choices where all terrible and held me back. Stuff like naively believing the company promises, working with obscure tech, switching stacks multiple times, stuck with the same company, etc.
I guess I'm a good example of what not to do.
I guess I'm a good example of what not to do.
did u stay with a company for long periods of time (4+ years) or did u frequently move from company to company ( switch every 1-2 years)
All 10 years at one company
do u regret not gaining experiences at other companies?
Not specifically. I regret not job hopping to increase money.
I've been in my current role for nearly 9 years, working in the field for 12+. I'd say that the one piece of advice is to not get stuck to a certain stack if you have the authority to make those decisions.
You're definitely going to make the wrong decisions about the stack you choose, or the way you design elements of your code, but that is how you learn.
Good problems to have, like scaling to thousands of concurrent requests, have been the greatest opportunities to learn. You may not get the answers right away, but they will come.
Before I get comfortable with learning any new language, look into the best practices for caching, or how easily that is handled. Your ability to know how and when to cache whether it's in memory if the language you use supports that, or through memcached/redis is going to make it less likely that you're going to need to do a complete rewrite in the future.
I first started programming 20+ years ago before I was 10 years old, with Visual Basic and the demo. Eventually moving to access, and PHP in the early 2000's in my later years in high school. Today, some of the larger apps I've written have been written in Go. Lately in the last few weeks, I've really come to love Ruby/Ruby on Rails, and for apps that I don't need to scale, that is going to be my go-to language for my own projects and client projects.
Would I suggest we rewrite everything or utilize Rails in my day job? Not a chance, because 1) my productivity is not worth it and 2) it's not the right tool for the job. Maybe if we had to write some back office software I'd recommend it, or I'd use Sinatra for a basic API/demo.
You're definitely going to make the wrong decisions about the stack you choose, or the way you design elements of your code, but that is how you learn.
Good problems to have, like scaling to thousands of concurrent requests, have been the greatest opportunities to learn. You may not get the answers right away, but they will come.
Before I get comfortable with learning any new language, look into the best practices for caching, or how easily that is handled. Your ability to know how and when to cache whether it's in memory if the language you use supports that, or through memcached/redis is going to make it less likely that you're going to need to do a complete rewrite in the future.
I first started programming 20+ years ago before I was 10 years old, with Visual Basic and the demo. Eventually moving to access, and PHP in the early 2000's in my later years in high school. Today, some of the larger apps I've written have been written in Go. Lately in the last few weeks, I've really come to love Ruby/Ruby on Rails, and for apps that I don't need to scale, that is going to be my go-to language for my own projects and client projects.
Would I suggest we rewrite everything or utilize Rails in my day job? Not a chance, because 1) my productivity is not worth it and 2) it's not the right tool for the job. Maybe if we had to write some back office software I'd recommend it, or I'd use Sinatra for a basic API/demo.
i see people around me jumping ship every two years for various reasons, but you've been with a company for almost 10 years, do you think that steadiness has helped you become a better engineer or has detracted from helping you gain experiences?
I think my position is unique to others. A year after I started, my wife and I had our first child, so ensuring we had a stable and steady stream of income was my priority above all else.
Along with that, the company I work for has been good to me through the years. I've enjoyed working with my co-workers and the projects I work on. While I may be able to make more working for another company, I do think that the atmosphere and ethos of a company bring a certain amount of value that I would be trading off. I may be wrong, but I have no reason to think otherwise at this point.
I've always been self-taught, and always tried to be working on something on the side, so I believe that has allowed me to keep up with changes and try new things to scratch my itch of not being complacent.
When I first started working at my full-time job, I was the only developer working on my project and was entrusted with choosing the stack I felt could get the job done. It felt very early start-up in that sense. Shortly after that, I began working on another product that I'm still working on today, and wrote the main components in Go and some back office parts in PHP. To help support me being the sole dev, we had a few other devs come in and rewrite the majority of the components in Java because back in 2013, Go wasn't as widely used as it was today.
I'm thankful that for the most part I've always been able to choose the tech or libraries I want to work with, within reason. I try not to push it too much, for example we use MySQL and Redis primarily for data storage and transient storage, but part of our app does use Mongo and that was a direct result of me trying to hop on the bandwagon early on that I now do regret because Mongo provides us no benefit over MySQL.
If I do want to use some obscure tech to test out, then I'll use it for my own projects. If I feel comfortable enough then I'll use that for my client projects as well. Only if it's something I've battle tested will I see if I can use it in my primary job.
For the first time in 5+ years I am not developing a client side-project in PHP or Go, I'll be using Ruby on Rails, because I'm at the point that the stability of the toolset and my productivity outweigh any performance gains that may be had with Go, and these projects are primarily back office that won't be doing a ton of data crunching or have more than a dozen users using it at a single point in time.
Along with that, the company I work for has been good to me through the years. I've enjoyed working with my co-workers and the projects I work on. While I may be able to make more working for another company, I do think that the atmosphere and ethos of a company bring a certain amount of value that I would be trading off. I may be wrong, but I have no reason to think otherwise at this point.
I've always been self-taught, and always tried to be working on something on the side, so I believe that has allowed me to keep up with changes and try new things to scratch my itch of not being complacent.
When I first started working at my full-time job, I was the only developer working on my project and was entrusted with choosing the stack I felt could get the job done. It felt very early start-up in that sense. Shortly after that, I began working on another product that I'm still working on today, and wrote the main components in Go and some back office parts in PHP. To help support me being the sole dev, we had a few other devs come in and rewrite the majority of the components in Java because back in 2013, Go wasn't as widely used as it was today.
I'm thankful that for the most part I've always been able to choose the tech or libraries I want to work with, within reason. I try not to push it too much, for example we use MySQL and Redis primarily for data storage and transient storage, but part of our app does use Mongo and that was a direct result of me trying to hop on the bandwagon early on that I now do regret because Mongo provides us no benefit over MySQL.
If I do want to use some obscure tech to test out, then I'll use it for my own projects. If I feel comfortable enough then I'll use that for my client projects as well. Only if it's something I've battle tested will I see if I can use it in my primary job.
For the first time in 5+ years I am not developing a client side-project in PHP or Go, I'll be using Ruby on Rails, because I'm at the point that the stability of the toolset and my productivity outweigh any performance gains that may be had with Go, and these projects are primarily back office that won't be doing a ton of data crunching or have more than a dozen users using it at a single point in time.
Great ask. I have 20 years of experience. In no particular order…
- Read great code: e.g. Redis
- Learn systems thinking: Book like Thinking in Systems, The Systems Thinker, or similar. Learn how to structure your thinking.
- Disagree well. Argue with data. Learn about people you work with to understand how they are wired and how they think (credit Ray Dalio’s excellent Principles book)
- Learn, practice, and hone above average human skills! Don’t be an ass. Listen. Be slow to criticize.
— Obsess about being awesome at communicating—1:1, group, written, presentations.
- Learn algorithms and data structures well so you have a firm foundation upon which to design solutions.
- Learn about how nature designs systems. Learn about fields outside yours (architecture, civil engineering, etc) to gain perspective on how they solve problems.
- Ask many questions!
- Read great code: e.g. Redis
- Learn systems thinking: Book like Thinking in Systems, The Systems Thinker, or similar. Learn how to structure your thinking.
- Disagree well. Argue with data. Learn about people you work with to understand how they are wired and how they think (credit Ray Dalio’s excellent Principles book)
- Learn, practice, and hone above average human skills! Don’t be an ass. Listen. Be slow to criticize.
— Obsess about being awesome at communicating—1:1, group, written, presentations.
- Learn algorithms and data structures well so you have a firm foundation upon which to design solutions.
- Learn about how nature designs systems. Learn about fields outside yours (architecture, civil engineering, etc) to gain perspective on how they solve problems.
- Ask many questions!
Don't mix 2 different things — become better engineer and career level up.
Sometimes they go together, but they are not really correlated.
My best career moves were:
1. get into small startup with really strong team and complicated technology in the beginning of the career — I rarely found such concentration of smart people and technology afterwards (even in big names i worked so far).
This was my best education in software engineering.
2. start my own bootcamp school and start teaching people — another great boost in hard and soft skills I couldn't imagine i'd get.
Sometimes they go together, but they are not really correlated.
My best career moves were:
1. get into small startup with really strong team and complicated technology in the beginning of the career — I rarely found such concentration of smart people and technology afterwards (even in big names i worked so far).
This was my best education in software engineering.
2. start my own bootcamp school and start teaching people — another great boost in hard and soft skills I couldn't imagine i'd get.
(I'm a dev with 16 years experience)
I joined a startup (20+ employees) and it was a great way to grow my career. In 4 years I went from Senior (in a team) to Lead (for a team) to Technical Lead (shaping technical decisions for all dev teams). Wore a bunch of different hats and got experience in many different areas.
Working-from-home was a really good fit for me. I can get hot-headed (not proud of it) and being away from colleagues and communicating in an asynchronous way gives me enough time and distance to cooldown and (most of the time) put forward the best version of my argument that I can.
Started contracting around the same time as wfh and in a weird kind of way, it also provided some distance. You just think differently about your relationship with any company. It can be scary at first because you know you're first on the chopping block when downsizing needs to happen but the upside is that you'll probably earn enough to set some aside as contingency.
Some people will say not to switch stacks but I've done it a few times (C# -> Ruby -> Node.js -> Python/Go) and I don't think it's hurt my career. My recent switch to Python/Go has really just been me getting bored at work with Node.js and wanting a change. Another side of it is that if you want longevity as a developer, you'll need to be able change stacks a few times in your career to remain employable.
I joined a startup (20+ employees) and it was a great way to grow my career. In 4 years I went from Senior (in a team) to Lead (for a team) to Technical Lead (shaping technical decisions for all dev teams). Wore a bunch of different hats and got experience in many different areas.
Working-from-home was a really good fit for me. I can get hot-headed (not proud of it) and being away from colleagues and communicating in an asynchronous way gives me enough time and distance to cooldown and (most of the time) put forward the best version of my argument that I can.
Started contracting around the same time as wfh and in a weird kind of way, it also provided some distance. You just think differently about your relationship with any company. It can be scary at first because you know you're first on the chopping block when downsizing needs to happen but the upside is that you'll probably earn enough to set some aside as contingency.
Some people will say not to switch stacks but I've done it a few times (C# -> Ruby -> Node.js -> Python/Go) and I don't think it's hurt my career. My recent switch to Python/Go has really just been me getting bored at work with Node.js and wanting a change. Another side of it is that if you want longevity as a developer, you'll need to be able change stacks a few times in your career to remain employable.
The single best thing I ever did to level up my knowledge:
I left a (huge) company that I had been working with for seven years, to work for a tiny company. It taught me just how little I really knew.
If you want to level up as an engineer, once your current company runs out of things for you to learn, change companies to the exact opposite. Shift from a large company to a startup. Shift from education-based to finance-based. Shift everything that you can, so that you get completely different problems.
I left a (huge) company that I had been working with for seven years, to work for a tiny company. It taught me just how little I really knew.
If you want to level up as an engineer, once your current company runs out of things for you to learn, change companies to the exact opposite. Shift from a large company to a startup. Shift from education-based to finance-based. Shift everything that you can, so that you get completely different problems.
All that matters career wise is whether you can leetcode. If you can, great! Go get a 450k offer. If you cant, get into management ASAP or move out of your developer role, because your pay is capped and theres no where to go.
* Be cautious of conveniences. That which you depend upon binds you and limits you. Your code cannot execute faster than the layers underneath it.
* Step away from what you know. I spent time running security audits and on a different occasion became the company A/B test engineer.
* I was promoted to senior for doing less work. I would finish the days work in the first two hours of the day and spend the rest of the time writing side projects.
* Learn something foundational. I learned XML Schema and wrote an original markup language before I learned to program. Jumping into JavaScript I already knew all about the DOM better than most JavaScript developers.
* Don’t start your career with an investment of time in frameworks. This makes you a less desirable hire to many shops of variable maturity. If you want to level up you have to be willing to put the pacifier and baby bottle down even if it makes you less attractive at first glance.
* Step away from what you know. I spent time running security audits and on a different occasion became the company A/B test engineer.
* I was promoted to senior for doing less work. I would finish the days work in the first two hours of the day and spend the rest of the time writing side projects.
* Learn something foundational. I learned XML Schema and wrote an original markup language before I learned to program. Jumping into JavaScript I already knew all about the DOM better than most JavaScript developers.
* Don’t start your career with an investment of time in frameworks. This makes you a less desirable hire to many shops of variable maturity. If you want to level up you have to be willing to put the pacifier and baby bottle down even if it makes you less attractive at first glance.
If you've primarily worked on B2B/enterprise software where the company makes a lot of money with a smaller user base, try working in consumer software where the company makes a lot less money across a lot more users.
If you've primarily worked on consumer software, do a stint working on B2B software.
The way you work as an engineer changes a lot among these two customer types, and there are valuable lessons you can learn and apply from working on each one. The systems design and scaling challenges can also be quite different.
Your versatility as an engineer who can recognize a wider variety of problems and define different solutions also improves.
There a lot of B2B-like problems lurking inside of big consumer tech companies. And a lot of things that can go faster and provide massive technical improvements if you deploy B2C thinking and tech inside a B2B company.
If you've primarily worked on consumer software, do a stint working on B2B software.
The way you work as an engineer changes a lot among these two customer types, and there are valuable lessons you can learn and apply from working on each one. The systems design and scaling challenges can also be quite different.
Your versatility as an engineer who can recognize a wider variety of problems and define different solutions also improves.
There a lot of B2B-like problems lurking inside of big consumer tech companies. And a lot of things that can go faster and provide massive technical improvements if you deploy B2C thinking and tech inside a B2B company.
* working in a consulting shop (for breadth of experience)
* working in a big company (exposure to scale I can't get any other way, though I didn't stick around long enough, tbh)
* working with a product for years and years. makes you think about ways to help future you in a way that consulting won't.
* blogging about problems I found interesting. to write a description of a problem is to begin to truly understand it.
* speaking. doesn't have to be at a bigname conf, even at a meetup will force you to learn.
* founding a startup. not for everyone, but super helpful to me in having user empathy, thinking about business process as well as code, GSD
* doing a stint as a technical trainer. really improved my grasp of the technology.I've been working in the industry for 15+ years (including internship). I've job hopped every few years (currently working for a FAANG company), but I know devs with similar experience who have had the same job the whole time. Both can be very successful.
I think the biggest differentiator between a good engineer and bad engineer is ownership. Care about your work (not to the point where you have no work/life balance) and be passionate about your craft. That's what separates a good engineer from a bad engineer.
As for your career, remember this is your livelihood. If a company is falling apart, go look elsewhere. If a company isn't giving you a raise you deserve, talk to your manager.
I think the biggest differentiator between a good engineer and bad engineer is ownership. Care about your work (not to the point where you have no work/life balance) and be passionate about your craft. That's what separates a good engineer from a bad engineer.
As for your career, remember this is your livelihood. If a company is falling apart, go look elsewhere. If a company isn't giving you a raise you deserve, talk to your manager.
Follow the volume. Work on things that have lots of users, lots of revenue, lots of transactions etc ... nothing exposes bad engineering more effectively than tens of thousands of requests a second or terabyte size transactional databases.
Going on 22 years or so, but the best move was going to a small, bootstrapped startup. I was Engineer #2, and after a couple years, also was the lead for the "org" which included a few other Engineers and a couple offshore people.
My responsibilities ran the gamut from zero to one architecture and software development, answering the phones, product management, running our infra, managing the budget, and everything else. I gained such a broad view of how things work, what customers want, sense of product, etc. that it's helped every other job I've had since.
My responsibilities ran the gamut from zero to one architecture and software development, answering the phones, product management, running our infra, managing the budget, and everything else. I gained such a broad view of how things work, what customers want, sense of product, etc. that it's helped every other job I've had since.
Treat each job as a university course you're being paid for. Most jobs, if you fuck up, nobody dies. In other words, don't kill yourself over it, it is not war. You're there to learn the material and get a passing grade.
And once you are finished learning, it is time to move on. Ask yourself regularly: What did I learn today? When day after day for several weeks your answer is "nothing", it is time to move on.
Make one or two close friends, and make friends with everyone else.
And once you are finished learning, it is time to move on. Ask yourself regularly: What did I learn today? When day after day for several weeks your answer is "nothing", it is time to move on.
Make one or two close friends, and make friends with everyone else.
this is great advice, its so easy to get caught up in doing that you forget that you actually aren't learning much.
Recognizing that employment is a marketplace, and thus the value I can provide might be worth 5x (or more) to Company A vs Company B (even if it's a similar title or role).
12 years here. Got certified. Grew network by getting outside the office for corporate marketing or other reasons. Found a job where I worked/ran the business side with technical aspects. Went out on my own, learned the value of earning on my own asset. Read a lot, always reading. Still a work in progress. I Burned bridges. Don't do that. Takes doing it enough to realize relationships compound and you don't want that going the other way.
The people around me made the biggest difference. Its not hard to find ways to work with great people. Everyone needs help in some form or the other, in this complex ever changing world we live in, and if you are paying attention to what other needs, you can be of use to anyone. And once interesting, driven people find you useful, doors keep opening.
I have been at my current company for 16 years.
Developing great people skills and helping people when you can has been a great level up.
Developing great people skills and helping people when you can has been a great level up.
FWIW, you might want to read this article by 'patio11: https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
I think one of the best things I've done is try a lot of different jobs. Wide experience on how different companies approach problems can really make you a super-generalist. It also keeps your tech fresh as you will learn lots of different skills / stacks at each job.
Two things:
1. Observe a great developer. How he/she think? How he/she approaches the problems? I was lucky and met Winsley back in 2008. Despite I was working only ~1 year for the company, this changed my whole life.
2. Do everything and try hard to do it great.
1. Observe a great developer. How he/she think? How he/she approaches the problems? I was lucky and met Winsley back in 2008. Despite I was working only ~1 year for the company, this changed my whole life.
2. Do everything and try hard to do it great.
I never made any "career moves" per se, but the best things I did in retrospect involved choosing to work around extremely smart and knowledgeable people early on, over opportunities that probably would have paid more.
* Focus on the value you produce, not on the stack or language.
* Don't over-architect for a future that might never come.
* Be a fly on the wall when users use your product. It will be terrifying but it will give valuable insights.
* Do good and talk about it.
* Don't over-architect for a future that might never come.
* Be a fly on the wall when users use your product. It will be terrifying but it will give valuable insights.
* Do good and talk about it.
Working with people who were much more experienced and/or familiar with what I needed to know than I was, and who had a welcoming approach to sharing their insights.