9 Ways for Mid Backend Engineers To Grow
When you’ve already landed your dream job, you can sometimes forget that the software developer needs to constantly expand his skills both deep and wide. Not only engineering but also communicative skills are critical in teamwork.
In this article, I will share my recommendations for continuing developers to work and learn more efficiently.
Take full responsibility for your task
On small and middle-scale tickets — take full responsibility and deliver.
That’s it.
It doesn’t mean you have to work nights and weekends to complete something if you underestimated the task. Instead, you communicate the delays/problems responsibly.
If you’re not sure how long something will take you, don’t guess, instead say “ I will investigate/evaluate this and will get back to you”.
If you understand the feature you’re working at is harder than you expected, then communicate your problem either at standup or directly to your lead.
Communicating problems and delays is what shows your responsibility and will to deliver.
Learn to decompose the large task into smaller steps
Handling one big task at once is a chore, do yourself a favor and split everything into smaller steps. It’s easier for you to code in smaller chunks, and it’s easier to communicate what you’re currently working on.
Until you’ll figure out what works better for you, at first, I suggest going with perceived application layers:
- API route
- API controller layer
- business logic layer — action, service, or whatever paradigm is used in your project
- model layer — persistence and DB interactions
Keep notes in your Jira (whatever) ticket and mark progress on each small step.
This advice natively transforms into the task estimation skill.
Learn to estimate tasks with a time range
Telling someone the feature will be complete in 1 hour will be a lie in 99% of cases. Sometimes you’ll finish earlier by 30 mins, sometimes later by 5 hours.
Instead, take time to decompose the task into smaller steps, then from your experience, you set the minimum and maximum hours each step will take.
After you have a full estimation of decomposed smaller tasks just sum them up, and you will get min/max for the whole feature.
Don’t worry that your estimates will be wrong most of the time, no one can do that right 100% of the time.
The purpose of this estimation is to inform your Lead, PM, CTO, and other stakeholders of the complexity that feature has.
Offer at least 3 options for any problem
Don’t say we can’t do this. Don’t ask your Lead “how should I do it?”.
Instead, take time and think of your options.
Software engineering is all about finding a compromise that will work here and now for your company, current stack, and developer availability in a given time.
I usually define levels of difficulty and time to market:
- easy/fast, but dirty — if I understand this feature is just an MVP, or we need to deliver fast
- medium difficulty — some compromises here and there to launch a feature, but keep a cleaner code base
- longest/best solution — when you do everything right by the book, but development will take the longest time
The second dimension is relative to your team’s available resources for features:
- easy — will use current stack and everything you already know
- medium — will use the current stack and an addition of some new technology
- hardest — will need a completely new stack, microservice, etc.
Next, depending on how you understand the requirements of this feature. Get ranged time estimates for all 3 options and present them to your team. Tell them about the pros and cons of any approach and then discuss.
Make Good Pull Requests
Do yourself a favor and run tests, type checks locally first. This will save your company’s CI/CD run minutes in case of failure.
Fix any errors you encounter.
Repeat tests and checks locally until 100% passes.
Create a draft PR, then do a self-review. Look for commented code, leftover debug code, and any code formatting changes (from lines you did not write for this feature). Fix them — they are so obvious, you’ll probably be asked to fix this anyways to keep the code base clean.
At this point it’s good to get a high-level overview of new additions, do they look okay? Can you understand the idea behind interactions that happen for new features?
If all is good, then finally mark it “ready for review”. Be a nice and responsible PR author, and make your colleagues a little bit happier.
Get a good IDE
My main stack is Node.js and PHP, and a little Python, so this advice is for you if you’re using a similar stack.
I recommend WebStorm, and PhpStorm, basically a Jetbrains product over popular VS Code. Those IDEs have built-in inspections and framework-specific plugins, they basically will tell you where your code can be improved.
VS Code is a good backup editor.
I have a series of articles about the PhpStorm setup for Laravel devs here.
Practice Test Driven Development (TDD)
You’ve probably already read about this a lot.
You can’t manually test your whole project after each change. You can’t manually test feature subsets after each change. Even testing a single feature over and over again after each refactoring is a pain.
But the best thing that TDD teaches you is thinking in decomposed layers of your application.
When you need to test API — then you will first think of the request structure you would like to have.
When you need to test a Service class — then you will think of public methods it’s best to expose and what input data is required to perform the task, what dependencies it will need to operate.
When you need to test your integration layer, like databases, or other storage, you’ll think of better schema design independently of other layers.
Next, you’ll have each layer working on its own and mocking other layer’s dependencies — the result is — your code is much cleaner. All your layers are independent, you can change one and not break the other.
Just write decoupled code from the start and release future self of headaches.
Keep the door for refactoring open. Write automated tests, that way you keep the opportunity for refactoring and updating open in the future.
Ask for help when you’re stuck
Don’t be shy to tell the team you’re stuck with something and ask for guidance — such interactions are your growth points.
You workflow should look like this:
- Take time to solve the issue yourself
- Try to get at least 3 possible solutions you can discuss with your lead with pros/cons and time estimates for each. Usually ranging from easiest to code to hardest.
- When you see a potential problem with something you work at — act before deploying, it’s easier to fix bad design from the start than later.
- Try to solve the problem yourself, then if no luck, describe all attempts you’ve done and why they didn’t work.
That’s times more informative than just putting a comment in a ticket “that didn’t work for me can someone help?”.
Learn a new stack that is close to your current stack
Build hobby projects with a full Software Development Lifecycle: from design to automated deployment.
For each stack, there are some adjacent skills you can learn to expand your knowledge.
- NestJS — advanced Redis, messaging queues, GraphQL, Go/Python, React, Vue, not recommending PHP as it’s a big paradigm change after Node.js.
- Laravel — Node.js, React, Vue, Redis Json, Streams, NestJS, RabbitMQ, Apache Kafka, SQL/NoSQL databases.
- For everyone— basics of DevOps — Kubernetes, GitHub actions (Bitbucket, Gitlab alternatives). I assume you’re good at containers and docker-compose already. CircleCI (recommended, free cloud plan with generous build minutes for solo projects).
To recap everything, here are all my recommendations:
- Take full responsibility for your task
- Learn to decompose large tasks
- Learn to estimate tasks with a time range
- Offer at least 3 options for any problem
- Make Good Pull Requests
- Get a good IDE
- Practice Test Driven Development (TDD)
- Ask for help when you’re stuck
- Learn a new stack that is close to your current stack
Hope this was helpful. Good luck and happy engineering!
