Why?
Not because of getting a big salary or fancy job title on the office doors. Those will eventually come as side effects of your knowledge and experience.
Mostly so you know how things can work (or suck) in different work environments.
Every article should have at least one cliche quote. So let's get this done
You don't know what you don't know
Let me tell you a little story.
When I started to learn to play guitar I was lost. Where should I place my thumb? How to switch smoothly from G chord to C chord? What type of strings should I use ?
Well here is the thing. In the beginning, I thought there is a single right thumb placement, only one way to form a C chord, and only the strings I bought my guitar with. Some of those things have worked for me some have not. The thing is I would be probably struggling until now if I dint try different strings, ones I didn't even know a few weeks into playing.
I would suggest applying the same thing to your career.
➡ Discover ➡ Try ➡ Evaluate ➡ Change or keep.
This article is as a usual opinionated overview of what I discovered during the nearly 10 years of my career
Company types
Companies have many flavors but in my humble opinion, they all fall into three main categories. I will try to highlight high level overview of benefits vs. sources of frustration in each of them
Big Corporation
Processes - They have it all figured out. From releasing code to upgrading your laptop to the newest version. Most of the problems have people dedicated to them you just do what you do best. On the other hand, sometimes your fresh idea needs to go through five layers of management to be eventually rejected god knows why which can be frustrating
Scale - If you get lucky enough and work with one of the flagship products of big corp you will encounter another layer of problems connected with scale. Designing or even creating system architecture at scale is one of the most interesting and horizon-expanding things software engineers can work on
Mature product - As a junior developer, this is an advantage. The codebase is battle-tested in production and (hopefully) written in a solid way. You can learn only by reading code seniors have written. As usual, this comes with a disadvantage. There are chances that the majority of problems are already solved and as time passes your work is reduced only to copy-pasting new features
Software House
Changing projects - In a software house, it is very rare to work on a project for more than 18 months. Projects have milestones and after completion, you are rotated out. This brings advantages like new fresh projects so boredom is reduced drastically but on the other hand, you don't have a stable team so sometimes those special bond between coworkers is missing. Also, you miss the "beautiful" part of maintaining your own code
Always being the external guy - This is natural. If you work for a software house you are essentially a contractor. I've seen exceptions but usually, you are treated slightly differently. I've seen projects which had two different sets of meetings with different depths of information provided - external & internal. Also if the company is struggling financially contractors are first to go
Tight deadlines - Although architects and senior developers are part of the initial contract agreement with the new client and they discuss project estimates in the end its sales department which puts the deal on the paper. The tighter the schedule the more money is to be made for your company. This often results in milestones that are tighter than it is healthy
Startup
Wearing many hats - In the beginning you get hired as an Angular frontend dev but in three months you are forced to write a new GoLang service and integrate it into the NoSQL database. You have registered a database account under your company email so now you are owner, maintainer, and overall go-to person for that service and DB. I liked it but some people feel overwhelmed.
No Processes - Exact opposite situation as in big corp. If you are used to them it can be challenging and frustrating. On the other hand, if you like to operate under the radar of e.g HR department this is the place to be :)
Not enough data - If you have zero or few customers it's a lot harder to make informed decisions. Most of the time you are guessing what might or might not work. It's fun and exciting unless you are the person who gets mentally attached to your code. You just can't. A big portion of the code is written to be thrown away get used to it it's natural.
There's a lot more to write about different types of companies. If you want me to put together a detailed post about differences I have encountered between them leave a comment 🙂
Product types
- Internal tool / library
- Publicly facing application
- Back office system
Different product means different business requirements.
I have worked on an internal library used by more than half of a dozen teams across the company. Gathering requirements, Communicating changes, designing APIs, making the codebase friendly to outside contributors was my daily bread.
On the other hand, working on publicly facing e-commerce solutions thought me the importance of SEO, performance, and super fancy pixel-perfect UI. You would never spend 3 months optimizing TTFB on the internal tool mostly because nobody gives a damn about it
There is no right or wrong in terms of product types. Just try as many as you can so you know what is the best fit for you
Domains
You are as many times
humanengineer, as manylanguagesdomains you know.
I have worked on projects in a hell of a lot of domains.
Software security, Fashion, Logistics, Finance, Government services. Real estate, Marketplace, Credit cards ...
Each of them was unique and had different challenges. At some point in your career, things eventually start to get repetitive no matter how much you are getting out of your comfort zone (new languages frameworks, etc ...). The less you are willing to experiment the sooner it happens. At that point, domains start to be the interesting thing. If you are not just coding shovel™ and getting involved in product ideas then the domain itself starts to be the fun part. Besides that, you can learn a lot from interacting with people from different domains
Conclusion
Throughout my career, I've experienced all of the above and I am thankful for that.
It was partly luck partly my own initiative. I do not encourage job-hopping in any way. Leave your job when it makes sense and know when it doesn't. E.g I stayed at one company a lot longer than I should but I enjoyed the benefits of having a great mentor. All in all, if you decide to leave try something new. It will help you immensely.
Top comments (0)