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.
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.
. 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. ;>
* 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
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.
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!)
I guess I'm a good example of what not to do.
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.
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.
- 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!
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 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 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.
* 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.
* 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 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 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.
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.
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.
Developing great people skills and helping people when you can has been a great level up.
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.
* 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.