Getting better at both sides of the stack
Whether you're starting to learn programming and web development or have a couple of years on it, you can be aware of the different tools out there that we use to solve common problems.
You can be constantly looking at what's out there. What updates on new tools or new tools themselves have come up. You're learning new ways to do things or increasing the skill in tools you're already familiar with.
And even you could be narrowing down your focus to 2 or 3 technologies for your particular role (whether that's Front, Back, DevOps, etc.)
But just because you're practicing your skills on the technical side, doesn't mean that you should be ignoring your other skills. Complementary ones that can make your work and the time at a job better and more productive.
Because remember that what you don't use or practice often starts getting rusty and then it won't be readily available next time you need it.
The fact that we're in the tech industry would mean that all that we needed to be successful are superb levels of skills in technologies right?
Well, not exactly.
You can be really good at your role and dominate the technologies of your stack, but it's no longer the 90's where you could do everything from a cubicle and barely have contact with anyone else.
And no. In case you're wondering, I'm not only referring to the skills of your stack if you're a front-end dev or a back-end.
I'm not saying that you have to become a full-stack developer. (Although if that's what you want to become then go for it! More power to you!)
I'm advocating for getting better at the skills of your tech stack and the skills of your "human stack".
So it would be like 2 stacks or a general stack of 2 different stacks...
A stack of stacks. Inception much?
All jokes aside. That other stack is composed of all the other skills that will make you far more successful than sheer technical skill alone.
You've quite likely heard about it before. Modern software is developed with teams. Nowadays, remote teams in different countries and even different continents.
Teams require proper organization. Proper coordination. Proper communication.
So as developers, our job is not only to code that super sleek UI with proper practices and clean code. It also requires being able to explain the choices of the patterns we used.
Why a nested
if else instead of a
switch. Why a typical
for loop instead of a
If you plan to advance in your career path, others will want to see both of those skills from you.
In bigger organizations, you might get away with being very good at a particular area of development and that's it. In startups, however, you'll have to wear different hats and be able to deliver on various fronts.
One of the things that would enable you to make that move from "beginner" to more "advanced" is realizing that the code written ultimately serves a purpose.
It's all well and good when the code is organized, clean, and with good practices. But it has no point if it doesn't fully deliver on the value the business expects.
That reminds me of a quote.
“There is nothing so useless, as doing with great efficiency, something that should not be done at all.” - Peter Drucker
Yeah, couldn't have said it better myself.
Being more practical about this, a few things to consider working on in the other skills stack.
Check your ego: Are you overprotective of your code? Do you have to be right when talking about a technical aspect? Can you receive feedback without getting defensive?
Disposition to change: Do resist change whether it is of code, or team, or even the project itself? How have you dealt with changing parts of the product or the team you are in? Do you seek opportunities for change to grow and improve?
Technical & non-technical communication: Do you know the skills required to tackle a project? Can you communicate the issues or difficulties of using one technology over another? Are you able to explain the current status of a project to non-technical members of the team?
Yeah, that probably sounds like a lot, but it's only a part of the puzzle. Don't worry though, you don't have to stop doing what you're learning and jump into a different environment and forget about everything else.
Use the Pareto principle to identify what's the 20% most important that you need in your current role and start from there.
Also, don't try to do this all by yourself. That's why there are communities out there of fellow devs that you can practice with and learn from.
Keep in mind that both stacks of skills can be learned and practiced in the same space. That's if you're intentional with it and recognize the different opportunities that will come your way.
That's all part of the process and the quicker you realize about it, the better it will be in the long run.
Keep working at it and you'll soon find yourself in a much different place than when you started.
That's it for this article. If you got all the way here, thanks a lot for reading. We'll see in the next one.