Whether you just finished a bootcamp, graduated from college with a computer engineering degree, or maybe even have a few years under your belt it’s hard to progress from your first job as a coder to a full-fledged career as a developer. You will need to spend time on both improving soft skills as well as technical skills. Short changing either of these won’t produce the long-term career goals that you are shooting for. Here are a few traits I’ve seen that ease this transition.
If you landed in tech because you saw a salary guide and thought that’s my ticket to the big time, then I wish you the best of luck. On a cautionary note, this will require either finding the right company that needs legacy skills while somehow staying afloat, or diligence on your part in staying up to date in an ever changing technology landscape
If, however, you love being challenged and get joy after cleverly solving a difficult problem, then all that is left is to put in the time and dedication to learning, growing, and accepting new challenges. Having passion makes it easier to invest the time and energy necessary to keep your skills current each and every year.
Development appears to be a solo activity, because it usually starts out that way for most of us. It rarely if ever turns out that way. If you are looking to be left alone in the corner coding all day you are limiting your usefulness to the company, and despite being irreplaceable you will be replaced.
You should want to be part of a team so that you can learn from others. Your peers will help you improve your craft, and one day you can repay the favor to other up and coming developers. Some things you should learn from your peers are coding standards, how code is organized, coding techniques, and how things are done in this company’s view of the real world*.
Without team collaboration and mentors your growth will quickly plateau regardless of your talent.
You now have training behind you, and have developed some level of competency and confidence in your abilities using a particular tech stack. How do you go about showing what you are capable of?
What work is beneath your talent and skills? None, full stop.
Charlie, that’s easy for you to say now that you have years of experience. Are you just trying to get out of doing the boring work?
No definitely not. Let me meander through a recent project, where I was in similar shoes. In my case it was a construction project. While I’m competent with hand tools and power tools this project was out of my comfort zone. Luckily, I had access to a few professionals that could not only do the work, but they could show me how to do some of the work.
There were parts of the project I couldn’t do because I didn’t have the requisite experience, and more importantly because I couldn’t see the whole picture. Left to my own devices I may have tried to drywall before all the plumbing had been fully connected. More than likely I would have at least forgotten to test the plumbing for leaks. Sure, I may have eventually gotten there, but it would have been costly, time consuming, and infinitely more frustrating.
What was I able to bring to this project without getting in the way too much?
I could have left all of that up to the professionals too, but I learned a lot along the way, got the project done quicker, and took some of the load off the professionals. I now have more confidence if I was ever stupid enough to do another similar project.
But what’s that got to do with you being a better developer? Are you ready to build a whole application by yourself that actual users will use, and more importantly expect to work consistently? Will you remember to test the plumbing before installing and finishing the drywall? What is the definition of a rhetorical question?
Here is my take on what you should bring to a project early on in your career
Do what the team asks of you. Try to understand what the processes are trying to accomplish. If you don’t understand, ask. It may be that it used to solve a problem, and your team no longer experiences that problem due to other mitigating processes or team maturity. File the processes that work away for later projects. For that matter, file the ones that don’t work away so you can avoid them in the future.
Review existing code in the application to understand the various components and technologies in use. This could be part of a formal code review process, or after the fact. Spend a little time doing this every day. Gather questions about code you don’t fully understand, and periodically ask your teammates.
Quality is not just for testers anymore. While testing may also be the primary focus of a specific role on the team, it is a whole team sport.
You are responsible for the quality of the application, so what can you do to improve it? First be open to participating in all aspects of testing. This could range from writing unit tests, to testing features that were deployed to a server for the first time, to testing a feature another developer wrote, to ensuring the UI is consistent, to ad-hoc exploratory testing.
You need to know how your application actually works to know how best to add functionality and fix bugs without introducing new bugs.
Second, work directly with the testers to understand their role and techniques. Have discussions early and often about how they are going to test your code, and any other expectations they have for the code you are writing.
Quality benefits from the team’s collective perspectives, so please bring your perspective to the table to build stable and useful software.
Pay attention in meetings to better understand the business context. Understand the terms the business uses and create a dictionary of terms, acronyms, etc. to better engage with your business partners. You need to understand what the business is saying in order to build a solution that solves their problems. Development teams should adopt the same consistent terminology in their code so you don’t need a special decoder ring to talk to the business.
Use your understanding of the business context when creating or refining stories, reviewing code, and testing.
Start out with small features that only take mimicking existing code. Ideally this would be across the full stack so you get understanding of the structure of code. This puts some of what you learned in Code Reviews into practice and may highlight subtle nuances of the code you need to work through to fully digest.
Be willing to try to stretch into different roles or technologies if it benefits the team. If you are only familiar with JavaScript but your back end application is written in C#, then learn about C# until you can at least read and understand it.
Several times in my career I’ve gotten stuck. There is only so much you can learn in a vacuum. The solution every time was to surround myself with other people. These people ideally have differing opinions, background, and experiences than you. This was especially effective when I found people that were willing and able to build into me.
One place I was able to find people like this was at user groups and conferences. Getting involved helped to get a different perspective outside the bounds of my day job. I learned about tech and processes that my company wasn’t using, yet. For example, I was working in a waterfall enterprise and learned about Agile through these interactions. I was able to challenge the status-quo with data from the larger industry, and start to make small inroads into shifting methodologies.
The other big benefit of participating in these groups was networking. Please don’t be scared of networking in this context. It’s just nerdy passionate people having conversations. These other people also gave up their Tuesday night to come learn the basics of Web Assembly too. What’s scary about that? Yes, it might be a bit frightening at first to put yourself out there in a sea of unfamiliar faces, but in no time, at least in Cincinnati’s tech scene, you will know the people that come regularly.
After getting involved and forming friendships I realized that I had a much broader pool of knowledgeable friends that I could tap into by simply asking for help. More important to this discussion, it has helped me land me several job prospects and offers throughout my career.
When you get stuck in your career search out those that can give you perspective or guidance.
A successful path is one marked by passion, a drive to continually learn, a willingness to stretch, and finding other like minded people. Yes, it really is that simple and yet somehow that complex too.
With the exponential growth of tech out there, be humble knowing that you don’t know everything, be willing to admit that, and be curious to find the next thing you need to learn.
* The real world will look vastly different from company to company, and none of these should be taken blindly as best practices