Year One

This is a short recounting of my first year as a software developer working on conflation for Bing Maps at Microsoft. Much of this will most likely be common knowledge to senior developers, but I wanted to share my personal views and provide a reference for some colleagues who will be entering the workforce soon. Also, a disclaimer, remember that not all of these tidbits of advice or experiences will reflect perfectly into your role or your how your team operates. All teams are different, and have different expectations for their code and products, I am only expressing what I have learned.

Start small and optimize later

One of the two big things that I learned, is that it is always okay to optimize later if the original goal isn’t performance. Sometimes getting a working prototype that accomplishes the goal can show flaws in the implementation that early little optimizations could never outperform and would end up being a waste of time. Now I don’t think that should put you in the mindset to ignore optimizations while prototyping. Keeping track of areas in your code that are easy optimizations should be documented somewhere for later. You may end up needing to squeeze a bit more performance out of your implementation and having a list of areas of available improvement can help considerably.

In addition to attempting to ignore obvious optimizations during the first prototype, another big piece of advice is to work in test-able chucks of code. DO NOT get carried away by refactoring large pieces of code all at once if you can help it. Start small and change component by component to help reduce the potential for new bugs to appear from forgotten changes. I think this might be some personal crutch as I tend to have an issue where I will attempt to resolve multiple code changes all at once. Think of it akin to coding ADD; it is extremely similar to my need to optimize little things here and there before it is even necessary. Maybe one day I will figure out how to ignore my inner optimization thoughts and just fix the bugs I set out to fix.

Design documents can save your day

Design documents are sometimes seen as large wastes of time and effort for no real gain. This is especially the case when starting as an early developer working alone on assignments for your university classes. I always found them to be such a waste of time since the scale of project that we were working on was so small that the design doc was way overkill. Now, I completely see the benefits and advantages of a good design beforehand: solve problems early, have distinct work separation, API contracts for shared code, providing a source of truth, etc. Now I think it depends on the scale of the component or system you are writing for you to justify fully working out a design document. Whenever a system or component is shared between teams, a design document is always a good idea to have a source of truth for both teams to reference; either as a client or as a provider.

A little DevOps goes a long way

One of the biggest time savers you can utilize, is to spend a little time optimizing your developer inner loop. This is the time that it takes to make a change, and then observe that change. For example, in a web application you make a change and perhaps also have a webpack server running to serve your code and auto-refresh the page in mere moments. In this case, little micro changes can easily be seen without having to wait too long. With conflation of maps data (the work I do), this can be particularly difficult since often you need to see the change reflected across the whole data set to verify its intended effect. This usually involves making some code changes on a large distributed system and then running the system pipeline again, which can take a bit longer than mere moments. Spending a little bit of time to decrease the inner loop time can be deeply rewarding and useful when adding new features or attempting to resolve some bugs.

Ask Questions

The most useful piece of advice that I can give is to ask questions. If you have any questions about how something works or how something operates, go out and ask someone. Even better, do some investigation beforehand but never be afraid to ask questions. Your co-workers are there to help you learn and assist you. I have the pleasure to work with some senior developers on my team who have a wealth of knowledge that I haven’t yet fully tapped. They helped me a large deal in my first few months teaching me all the technical stuff (machine learning and conflation), but even some of the non-technical things (setting up my 401k contributions). There is always something to learn from someone else’s experiences, so make sure to take advantage of every opportunity.