Sharing some tips from my experience as a full-time developer over the past 2+ years. I've also added references to some of the tips in case you want get more information from the source (recommended).
1. Add some theory to your practice
Many developers, myself included, focus most of their time on implementation without learning the underlying concepts of the tools they're using. There's a reason why the top tech companies place so much emphasis on problem-solving, algorithms, and data structures: if you have solid fundamentals, then you'll have an easier time to learn new concepts.
This doesn't mean that you should try to learn every tool you touch inside out. But you should understand the fundamentals of the tools you use in your day-to-day. For instance, if you're a front-end developer, you would be more valuable if you not only know the latest framework but also understand how the browser fetches the page, renders the DOM, processes your code, etc.
Sure some concepts are harder to learn picking up the latest framework, but those core concepts are more reusable and will make you a more valuable developer.
So next time you're trying to decide between Vue and ReactJS, make sure you deeply understand the problems that each of them solves and how they solve those problems.
2. Use comments to explain the "why" not the "what"
Some purists will tell you that code should be self-documenting but in practice that's usually not the case. Even if you write the cleanest code in the possible, chances are there are some details that are lost in code that can be better communicated in a comment. Remember that the target audience of your code is humans, not machines. So we should make it as easy as possible to understand.
I'm always grateful to my colleagues and my past self when I find myself working on some code where the business logic or the reasoning behind an implementation decision is explained. This has saved me countless hours of trying to figure out why the code worked the way it did.
However, explaining what can mean that your code is not clear enough for the reader to be able to interpret what it's doing from reading it. If you find yourself doing this, then your code might be too complex or is poorly designed.
References: Clean Coder
3. Try DDD (Documentation Driven Development)
Don't get me wrong, I'd choose writing code over documentation any day of the week, but documentation is what allows other developers or users to use your project. This is especially true for libraries or services since, as the developer, you're the most knowledgeable about how the product works and therefore are the most qualified to document it.
Honestly, for me most of the time the deciding factor between multiple libraries or services is the quality of the documentation; if the documentation is lacking or too difficult to follow, I move on to another option. I've been burned by having to dig through a library's source code to figure out how it worked because of the lack of documentation and I'm sure you been as well.
Part of the pain of writing documentation can be alleviated by writing it BEFORE you write your code the same way you'd write tests before the code in Test Driven Development (TDD). This is the main concept of DDD. If you always document your code before even writing, you'll also force yourself to develop a more concrete understanding of what the change requires, which, from my experience, translates into a cleaner implementation.
Of course, documentation is not limited to big projects or libraries and services. Even your small project can benefit from it. I've started documenting things like how to bootstrap and run the project, known bugs, design decisions, etc. in my small projects and they help tremendously. I always forget these things over time, so it's great to have them documented so I can always pick up where I left off.
Resources: Medium post, Gist article, Software Documentation is like Sex
4. Simplify your development workflow
Do your unit tests take 1 minute to run? Make them run faster run in under 5 seconds.
Do you have to manually restart your local server every time you make a change? Use a tool like nodemon to restart it automatically.
Are you manually formatting your code to meet a set style guide? Use a linter like ESLint and configure your IDE to automatically format your code.
You get the point. As developers, we enjoy solving challenges and shipping cool features, so why waste time on repetitive tasks? If you frequently perform the same task throughout the day while developing, chances are that task is a time-sink and should be automated.
References: The Effective Engineer
5. Be honest with your boss about deadlines and delays
Be very open about any issues you run into that may skew your estimate of a feature or fix; the earlier you notify management or your lead about a potential delay, the more time they will have to make adjustments to compensate.
Think about it from their perspective; managers need to communicate priorities and deadlines with customers and other stakeholders. So the earlier you let them know, the earlier they can notify stakeholders and adjust the roadmap as needed. In addition, it lifts takes the pressure off of you having to try to meet a deadline you know is impossible.
As an example, imagine that you're working on a 2-week project and after the first week you realize that the task is much bigger than imagined. If you're honest with your boss and tell her the task will take you an extra 2 weeks, she'll probably find a way to push the deadline. But if, instead, you wait until the day before the deadline, then your boss will likely be very upset because it means she'll miss the deadline with very short notice to stakeholders.
References: The Clean Coder
Top comments (0)