Become A Better Developer Today
While technical skills are always useful, even the most talented developer will fail to be noticed (and appropriately compensated) by management if they aren't effective in their work. If you've been around a while, you've probably noticed that not all of the most skilled developers are recognized for the quality of their work, with many languishing for years in senior developer roles. Worse still, you've probably seen developers whose skills and knowledge were mediocre at best who were promoted over and over again.
While it's a common refrain in this industry that good development practices aren't respected, that's not really the entire picture. The real deal here is that "good" development practices are only going to be rewarded if they actually produce value. Further, there are plenty of good practices that a developer should engage in that have little to do with code and have everything to do with actually providing value to the people signing your paycheck.
If you want to be a more effective developer and to have that adequately recognized by management, you have to change your patterns of behavior so that your technical skills are actually visible and acknowledged. For your skills to really shine through, you have to get rid of other problems that can make you look bad in spite of "mad technical skillz". Further, if you follow these practices, you'll often find that they have a side effect of forcing your technical skills to improve as well.
If you want to be a better developer starting today, there are a lot of things you can do to see an immediate improvement in how other people perceive you. Not only does this make it more likely that you will get recognized for your development skills, but it makes you more useful in general. This usefulness will not only make it easier to make more money, but it also puts you in a much better position to improve your own skills as a developer.
Episode Breakdown
Consider second order effects
Every action has a reaction (and most non-actions do as well). A lot of problems come from failing to anticipate second order (and following) effects. For instance, adding an online store to your application also implies additional regulatory and security compliance costs. Second order effects aren't all negative. Sometimes they create opportunity as well. For instance, the online store mentioned previously might provide the opportunity for further product customization for your buyers. The consideration of second order effects will help you write better code in anticipation of likely business needs, and asking questions about second order effects will help you build your network outside your department, which is very helpful for a lot of the other things we are suggesting in this episode.
Optimize for team efficiency and be vocal about it.
Good developers fix their own processes for better efficiency. Great developers do the same for their team. You shouldn't be competing with your teammates. If you are, that's a very bad sign. Instead, if you are helping your team be more effective as a unit, your contributions will (should) still be noticed, and you will create more value. While you may not have the leverage to actually MAKE your team use better processes, you can still lead them to implementing better processes by showing how those processes make things easier for them.
Learn how the money comes in.
Many developers think they can just come into the office, write some angular code, and be done with it. However, the truth is that the value of your code is always based on how that code impacts the flow of money in your organization. Learning how the money comes in will also help you position yourself within the organization. When you understand how the money flows through the business, it makes it easier to position yourself to be closer to the money coming than to the money going out. Successful companies try to optimize by increasing the amount of money coming in and decreasing the amount of money going out. This is always happening, but the process speeds up during an economic crisis (which we are probably in right now). Being in a revenue center is better than being in a cost center. If you are considering second order effects as previously suggested, you'll get more attention increasing revenue than you will for decreasing costs (at least under normal circumstances - see later discussion for more).
Determine values based on behavior rather than statements.
When your manager says that they value code quality over speed of delivery, does their behavior match that assertion? If not, you should optimize your behavior based on what their behavior implies rather than what they say. Frequently, people in a corporate environment will say that they prioritize things that sound nice, rather than what they actually prioritize. You see this all the time with managers who claim to prioritize code quality, but frequently rush development into pushing out nasty hacks. Behavior is a second order effect of one's values. When someone has a lot of influence over your future quality of life, you do well to optimize your behavior such that it meets that person's actual values, rather than the ones they are verbal about. Be aware also that the values of the group are not the sum of the values of the individuals in that group.
Say "I don't know"
Pretending that you know something when you don't is a short-term optimization. While you can certainly "grow into" a position, being overly optimistic about your ability to do so is a recipe for disaster. Further, if you regularly imply that you know things when you don't, people begin to actively distrust anything that you say. People are inclined to trust other people with known flaws and weak spots than they are to trust someone whose weak spots and flaws are unknown (better the devil you know than the one you suspect...).
Build systems rather than actions
Rather than trying to remember every single action you need to complete, focus on building workflows and processes for yourself so that you DON'T have to remember things. While it's easy to believe that you'll remember to do things, it often doesn't take much disruption at all for you to completely forget and drop the ball. You need to build systems that are resilient to changes in your environment, emotional state, and schedule. There are a lot of ways to achieve this, from checklists to automation to various forms of habit construction. You'll probably use a mix of these, but you need to be actively making sure that you are always improving in this area. This can also be a backdoor way of improving team processes. Try something new out on yourself and then propose it to the team.
Cultivate an intel network
If your only friends at work are other developers (or developer-adjacent people), you're doing it wrong. Not only are you missing out on a larger perspective about WHY you are building the systems you are building, but you are also building a very dangerous bubble. Organizational silos develop naturally as an organization grows and are completely normal optimizations. However, they tend to persist longer than they are useful. If you can break outside your own silo, there is often a lot of opportunity for providing value. If you are building internal software for a particular department, it's very useful to have someone you can talk to in that department for clarification. While you can do this through product owners and project managers, it's entirely possible that those people are not the people using your software every day. This can also help the people on the other side, as they often have very useful ideas about how they can get more done, and you can help push those things through.
Correct your schedule
Figure out when you are most productive doing certain tasks and try to do them then. Avoid doing tasks during times that aren't optimal. Lower priority tasks (that still need to be done) should be done during the time of day when you are less effective at your higher priority tasks. That way the work doesn't pile up, but you don't lose productivity to low priority junk. You should be actively protecting your best work time to the degree possible. Before getting upset at other people for messing up your best work time, make sure that you aren't doing so. Only after getting out of your own way should you start talking to management about getting others out of your way. Fixing your schedule may require you to fix your sleep, manage your time better, or even manage your distractions better. However, if you do manage it, you'll often see huge gains in productivity along with a reduction in stress.
Solicit feedback
You should be trying to tighten feedback loops when you can. If you find that you do things and don't hear whether they were good or bad for weeks (or even months), then you need to figure out how to get feedback earlier. Similarly, with automated processes (such as automated builds/deployments, and tests), you will improve your productivity the earlier you find out about problems. Don't misunderstand negative feedback as being feedback that makes you feel bad. Negative feedback in an engineering sense is nothing more than a course correction. The faster you can get this feedback (and the more quickly you can respond to it), the less effort you waste. Be careful about when and how you solicit feedback to ensure the quality of that feedback. You can get incorrect feedback if you are not paying attention to the bosses' mood (or to problems with an external system).
Ask better questions
Instead of asking questions when you first run into a problem, first attempt to research the problem until you get stuck. Only when you don't think you can get an answer, or when you have committed too much time to research do you interrupt someone else to ask. This does several things for you. First, it makes you capable of solving your own problems and causes you to get better over time. Second, it means that you aren't constantly going to others with dumb questions, which protects your reputation. When asking a question after having done the research, don't forget to also ask about improving your process of researching things on your own. The other person is probably better off if you come to them with fewer questions, so they typically will be happy to help you get better at asking questions.
Apply the pareto rule
20% of the work produces 80% of the results. 20% of the remaining 80% of the work produces 80% of the remaining 20% of results. Essentially, there are diminishing returns to any set of improvements, and you should bear those in mind. If you don't know what 20% of the work will produce 80% of the results you need, then you either need to start asking questions to determine that, or start trying to test to figure this out. As developers we have a tendency to over-optimize systems that we work with. While this can be very helpful building systems at scale, it doesn't work so well when one tries to optimize the functioning of an individual or a team. Process improvements tend to compound over time, so if you can make slight adjustments that have huge returns on investment, this can often free up resources that can be used to perfect things later.
Tricks of the Trade
Communication with some people can be very frustrating. Especially when there are barriers like language or time delays in responses. Sometimes though, you can be completely correct in what you are saying but still be part of the problem. This can happen if you are using unfamiliar or overly pedantic terms with people who may already struggle to understand what you are saying. When you have communication issues take a moment to step back and look at what you are saying or writing and compare it to what you are trying to accomplish. You may find there are differences in the two.