So, you’ve graduated with a CS degree, gone through a bootcamp, been through an apprentice class, etc. Congratulations! Welcome to this wonderful, interesting, crazy world of tech. There is a vast variety of tools available for you to use to create something fantastic. The boundaries of what you can build are only limited by your imagination.
With so many avenues to explore outside the classroom environment, figuring out how best to continue to improve your skills can be daunting. Detroit Labs developer Stuart Kent originally put together the following list of topics to help steer the next steps of freshly graduated Detroit Labs apprentices. We hope that you find it useful, and welcome your opinions and feedback on these suggestions!
Learning and self-reflection
- If you don’t know what your weaker areas are, spend some time thinking about it. If you thought about it and still don’t know how to identify weaker areas, talk to a senior developer at work or that you know outside of work. If you think you don’t have any weaker areas, guess again. We all do! And that’s OK. The key is to identify and address them.
- Focus on continuing to learn and addressing your weaknesses while at work. You can do this in a couple different ways:
- Choose to tackle the most relevant tasks on your projects. Run it by the team at stand-up (daily project team meeting) if you’re worried that time might be an issue. Keep everyone posted with accurate progress reports (even if the report is simply “yesterday I read a ton about X, so while I didn’t write any code, I should be in position to make a good attempt today”). The vague description of “still working on this” isn’t that useful, and senior devs won’t be able to tell when it’s a good time to offer some help.
- If you’re lucky enough (as we are at Labs) to have self-directed time each work week, use it wisely – pick fun hack day tasks that will also teach you project-relevant skills.
- If you are in an environment or assigned to a project where the above is not possible, make sure you are soaking up as much information as you can while on the job. Then study these topics in more depth after hours.
Use your resources appropriately
- The codebase, the documentation, tutorials, and Google should be your go-to sources for figuring most things out. Hacking away at something is by far the best route to understanding it inside and out.
- Look to experienced developers to help you solve particularly tricky problems. You should be able to preface your narrowly focused, specific questions with answers to all of the following:
- What exactly are you trying to achieve?
- What have you read up on/tried so far?
- What has worked, and what has failed?
- What are you stuck on/what do you not understand clearly?
- What are the hypotheses you have formed, tested, and found fault with?
Approach coding tasks systematically
- Figure out which parts of the existing codebase you will need to work with to complete your task (i.e. get familiar with how to navigate efficiently within Android Studio, Xcode, etc.).
- Figure out which parts of the application rely on those parts of the codebase (you must use the code to do this, not the application itself).
- Armed with this context, start thinking about how to implement your changes:
- Does the relevant code only affect a single part of the application? Lucky you, you probably won’t have to make significant structural changes.
- Does the relevant code affect multiple parts of the application? Boo, it must be Monday morning. Spend some time figuring out whether your planned changes will break functionality in any of these spots. If so, you’ll probably need to update the existing architecture before implementing any changes.
- Is similar functionality already implemented somewhere else? Can you draw inspiration from it? Or would refactoring to share this logic (perhaps at a different level of abstraction) be more appropriate?
Get involved in PR conversations, even if you didn’t write any of the code
- They represent the results of (a variant of) the process above. You can see many examples of how others approach making changes. If you’re fortunate, you may be able to follow along commit-by-commit.
- It’s easier to try to figure out the decisions someone has made when you are looking at a PR that addresses a specific task (rather than just browsing the entire codebase, which has been evolved asynchronously, by multiple people, may be stale, and must manage many competing concerns).
- Ask questions if you have them. Be nosy.
Pay lots of attention to detail
- When you started learning, getting conversant with the basic concepts was more important than nailing every. last. detail.
- Now it’s the details that are important, and that will make the difference in your success. At this point, you are expected to be able to independently learn new concepts as you need them, so senior devs will be looking for:
- Close-to-perfect matching of design comps, because they are what your client, boss, CEO, etc., signs off on
- The cleanest code possible, because the code person X writes today is the code person Y might have to jump into, understand, and alter 6 months from now, and we all like each other, right?
- Thorough tests for (at least) new/changed APIs, because they act as documentation for the intended behavior of your changes.
Start monitoring developer community news
I follow a lot of different feeds for work and personal interest, but some good places to check out are:
- Weekly newsletters about development or development in your specific expertise.
- Blogs or updates put out by the platform’s company (i.e. Android developers, Apple developer, Swift developers, etc.).
- Follow blogs and Twitter feeds for big name developers in your language. They are usually testing, trying, and hacking most often and have likely made libraries that you will regularly use on client projects. Their insights are what many senior developers look to.
At times you may feel like you are banging your head against a wall and that you can’t make it, but I promise you that you can. Perfect the basics, build on what you know, hack like hell, and one day you will be giving great advice to junior developers that look to you as a mentor and colleague.
