In the following article, I want to share with you some insights that I have gained so far during my software development career. Let’s take a look into a couple of coding and no-coding pieces of advice that can easily boost your career as a Node.js developer. Some of them are fairly easy to apply immediately and I can guarantee that they will make your work easier.
Focus
As developers, we create solutions in a dynamic and constantly changing environment. It’s really hard to keep up with the new cutting-edge technologies emerging all the time. Especially when it comes to the Node.js world. Sometimes you might feel overwhelmed thinking about mastering every single aspect when the new technology is coming out. And if you’re not up-to-date, you’re starting to stress out a bit with the feeling called the fear of missing out.
What if I tell you that almost every single piece of software nowadays is an evolution rather than revolution? What about extremely trending stuff like Machine learning? The technology was able to recognise the alphabet in the beginning of the ’80s followed by much research done decades earlier. For that many years we were limited with computational power and amount of digitalized data. Things changed in the time where almost every one of us has a super computer in their pocket and produces enormous amounts of data every single day.
Currently, each applied technology has some living idea under the hood. A metaphor that makes building blocks worth being concerned about. Think of the new framework you’re going to pick in the terms of how my team and my product would benefit from that? Maybe you would be able to bootstrap your project in the early phase of development. Or integrate an additional data access layer into your production software. There’s a huge chance that you’re going to integrate a little functionality of this and that. Spot the places where it may interact with your domain model and make that integration pluggable – for example by applying ports and adapters architecture. And prepare your application to evolve.
Frameworks are crucial in the modern software and help us reach our goals faster and more reliably. Nevertheless, they also have a small drawback: they may live much shorter than our business domain. We should take the profit of applying them instead of causing a lot of pain during the development. Don’t let them rule you and try to apply the loose coupling between their internals. It’s also an important question to check from the business perspective that almost no one from the software team asks: how long would that software live? It’s more like opening a jar with a hammer. Sometimes it is good enough.
Focus on the things that are important for the business side of your project. It’s the natural way that during the development the amount of uncertainty drops when we are reaching the end of the delivery process. Your code is nothing more than executable, codified knowledge, that everyone agreed on. Don’t be scared to test out and break things fast. It’s much easier to fix things with populated feedback rather than waiting for the perfect moment and constantly polishing your project.
Your project does not hang in the void. Success depends on the people that are participating in it. Establish clean rules of the communication process. Keep everything in a single source of truth and be kind to other team members. They want to work in the same great atmosphere just like you.
Thinking about joining Espeo? Check out our open positions Careers page and apply!
Testing
Have you ever had a feeling that you’re afraid to change something in case of breaking another part of your app? Or perhaps you’ve never suspected that your modification would break something else in a different place in your application?
There’s a method of breaking down the stress that we often introduce: testing at various levels. Either by proving a match for clients’ requirements in acceptance tests or by proving that a single function in your codebase is free of bugs.
In general, testing your application should make you feel comfortable when applying changes. Even if your application tends to be more difficult to work with and it seems that you need to reorganise some components by refactoring. This is basically the first step to do it. Before changing internal structure, you should guarantee that it has exactly the same behaviour as previously. Thousands of lines of code can be removed with no hesitation with well-designed tests. With such an approach, you’re operating on a vast higher level of abstraction.
What makes your tests well-designed?
It’s significant to pay attention to the scope of your tests and component sizes in your code. If you need to create an entire object structure, apply some external configuration and then apply checks. That would be a hotspot to break out the problem into pieces, apply some bootstrapping techniquest by delegating the creation phase, for example to factories. Tests would lead you to a more modular design of your application.
Tests have to make you confident that they cover the functionality. Nothing less, nothing more. By intention, tests should reduce the uncertainty periods by shortening the feedback loop by delegating from the more resistant to boredom machines.
You need the results fast. According to the Nielsen-Norman research, users tend to lose their attention when execution time rises above 10 seconds. How does it apply in our software world? We tend to postpone test execution to the pre-commit phase. Or even delegate that to some external CI pipeline if tests are getting much heavier. For a test-driven approach, the test should give you feedback almost immediately after hitting the save button to don’t break the flow of thought. How to do that? By applying modularity and in-memory implementations of all things that are time consuming: IO.
Tests are also an executable form of documentation. If your implementation doesn’t match the described rules, failed tests won’t let you pass further. We wouldn’t say the exact same thing for standalone files and either – comments in code – those ones might be outdated. For executable test cases, it’s clear: it shines in the beautiful green color or indicates you to apply some fixes. Think of testing in terms of onboarding new people to the project. The newcomers would have living documentation that they are able to interact with and there’s a higher chance to let them jump in faster and make them able to commit to the project from day one.
Remember: this is a feedback loop and it’s more likely to resonate within different stakeholders of your project. By creating acceptance tests as executable test cases, your client knows what is done and is free to act faster. And of course to give you feedback!
Organize
Do you know the approach of less is more? It’s not only the recent trend of minimalism but also of higher-management level, well-assessed work organization methodology. By the beginning of the ’00s, David Allen had published a book entitled Getting Things Done. He described the framework of organising the stream of tasks in a couple of simple steps: collect, process, organize and plan. With the main principle of getting rid of the things that are not necessarily important at the time. Instead of that, the focus should be on stuff you’ve already planned to do. These ones are your goals. In general: by reducing the amount of chores or trivial things, you are creating the space for more creative tasks.
Martin Fowler and Kent Beck give advice on tackling being overloaded in their book Planning Extreme Programming. You shouldn’t think of having not enough time, rather think of having too much to do. They give crucial advice: You can’t give yourself more time, but you can give yourself less to do, at least for the moment. It’s OK to prioritize and not do some things according to business oriented reasons. Think of tasks that it is safe to delegate or are applicable for automation.
When switching between focus and relaxation modes, you can try to dump the current state of your mind. For example when you grasp the things you’ve been working on instead of starting from scratch over again when you come back. It’s similar to applying the core dump file when debugging an application. Instead of navigating step by step, you’re applying the exact state of the last execution to continue the investigation. So when someone wants to interrupt you, give yourself a couple of minutes to prepare the core dump of your head to save time in advance when coming back.
Your Environment
Let’s focus on the most significant factor that leads you to your success: your closest environment. To complete the career boost strategy presented in this article, it’s crucial to find yourself a right place to grow. Seriously. Your excellence depends on the variety of projects you’re putting your hands on and problems you need to face. That works for both various business domains and technical aspects. The expertise comes from exposing yourself to experiencing new things and challenging your previous thoughts.
The perfect option would be a knowledge-centric place full of experts from many project domains that want to share their experiences: technical, organisational and business related. These are people you can learn from and that might guide you in your career path. Their experiences can be passed in various ways: including workshops, keynotes or even direct AMA (ask me anything) sessions. The choice is up to them. Every single chance to take advantage of these guidelines is priceless – and pushes you forward. You and your entire team by spreading the growth mindset and knowledge spreading atmosphere.
So my advice on that is to take some time to find a place where you have the possibility to grow and the support you need to grow. At Espeo, we are following the best software engineering practices as much as we can, especially Test-Driven Development, constructive Code Reviews and Pair Programming. We act to maintain the highest quality of software by spreading the knowledge across our teams because we believe that programming is not a zero-sum game. Everyone can benefit from this approach.
The following article has been written by our Senior Node.js Software Engineer, Wojciech Ossowski.
