Tips to Go from Junior to Pro

I’ve had the pleasure of working with some incredibly talented developers in my career. As both an individual contributor and manager, I’ve seen what it takes to become a senior developer capable of owning and managing high-stakes projects in an enterprise environment. Becoming an accomplished developer undoubtedly takes a lot of time and efort. These are some tips that will improve your code quality and make this transition a little bit quicker. In no particular order:

1. Write things to be maintainable long after you’re gone. Just because you fully understand how something complex works, doesn’t mean the person looking at it 5 years later will. Avoid designing Rube Goldberg machines. This is common with developers coming out of school used to short-term assignments.
2. Comments and clear variable names go a long way for readability and maintainability. Use them.
3. Measure twice, cut once. Briefly sketching a pattern or architecture in a notebook before you write a single line of code can save a ton of time down the road, even for small a feature.
4. Not being able to trust the state of something in the database is the kiss of death. Having extremely tight control over any state changes for a resource in your database is essential.
5. Use one single state over a combination of status flags that derive state. For example if you’re running a book store, a book could have a state of “used” or “new” instead of having status flags like “hasBeenOpened” and “hasBeenSold” which combined would derive the single-line state.
6. When dealing with related data, use transactions to ensure data is updated at the same time. If you’re using an older database that doesn’t support transactions, have a replay mechanism available so if something were to be replayed from a bad state it transitions to the desired state.
7. Knowing when to make things idempotent versus throwing an error is a skill. Generally I’d err on the side of idempotence. In the case where an operation retrying is a sinister sign of a bigger problem, then you may want things to error and breakdown before that occurs.
8. Good error handling, like propagating helpful errors from the backend, can be tremendously useful when debugging an issue on the front end.
9. Error messages should be helpful but not too specific. Raw errors should never be passed back as they could give expose important system information which could be exploited by a malicious actor. Security through obscurity is useful when used on top of strong security practices.
10. Logging software is invaluable, however logging too much will dilute its effectiveness. If there are alerts that constantly get ignored or don’t require action, they should be re-evaluated.
11. Keep little to no logic inside the API layer of your application. Instead logic should live as close to the resource it’s touching as possible. This will make your code more reusable as well as help to preserve key patterns if similar functionality is needed in another part of the codebase.
12. Consistency is key, parameter names across an API surface should share naming conventions. Responses should share a standard format. Inconsistencies in the API are generally the first sign that something has been hacked together.
13. When reviewing code, just because something works doesn’t mean it’s done right. Giving constructive feedback and expressing any concern is essential. Don’t look at it as criticizing someone else’s work. When your review is on code that introduces a bug or causes an issue, you are equally as responsible as the writer.
14. Consider performance and scaling. This separates hobbyists from enterprise-level devs. Is this something that needs to run serially or in parallel? Are the database queries hitting a good index? Will this operation work the same way on the millionth attempt?
15. Be careful of queries that don’t have a limiting factor on them, like date or size, e.g. queries that look up all documents in an initial “created” state. If there are a ton of created, and then later abandoned, resources in your system, this query will balloon in size and degrade in performance as your data grows.

Part I: Picking a Path

In my last post I explained why I left Wall Street in early 2017. I didn’t feel like the work I was doing was important, and never truly felt connected to it. As a bond trader working the phones, I thought that increased automation would steadily displace humans and reduce compensation. The fact that there is still not a central exchange for bonds to trade and the majority of large bond trades are done over the phone blew my mind. Companies like MarketAxess (MKTX), which operate a fixed income exchange platform, are seeking to change that. Their enormous growth in revenue and market share indicates that my initial doubts about the long-term career prospects of a bond trader were legitimate.

While surveying my options before leaving Wall Street, I spoke with many colleagues and peers. These conversations helped narrow my options down to three final choices. The first was going back to school for an MBA, second was applying for jobs in management consulting, and third was teaching myself to code and moving into software development.

1. The MBA Option

The MBA option seemed like a logical move. After all, moving from a two year investment banking stint into a master’s program is a well-trodden path for indecisive college graduates. However after using my bonus to pay off all my student loans I was not keen on going back into debt. Plus, after an undergraduate business school education, I was worried I wouldn’t be learning a lot of new information. I sought out advice from professionals in my network and the consensus on an MBA was that it was great for making connections and performing a career pivot, but that you wouldn’t learn a ton of new information and it was very expensive.

2. The Management Consulting Option

Management consulting seemed like a better option at the time because it did not come with the terrible cost of an MBA. It would allow me to work on different projects of different size and scope and broaden my career exposure. This was something I desperately craved after working in a highly specialized trading role. I reached out to my professional network again for information, as many of my classmates at Emory had gone into management consulting. The feedback I got again was mixed. While you sometimes got to work on cool problems in cool cities, other times you got sent to a small city in Wisconsin, in the winter, to work on a problem you weren’t interested in. The average week consisted of a crack of dawn Monday morning flight, a week spent in a hotel room, and a return flight on Friday. Experiences varied wildly between firms and teams, some were enjoying their time as consultants, others were showing the same signs of burnout that I myself was feeling. The one thread that seemed consistent amongst my peers was that no one saw management consulting as their long term career. This was a good way to spend some years when you’re young and energetic and get experience before moving into something you were more interested in or offered a more sustainable lifestyle. If I had a similar experience as my peers, I would again be looking for a new job in a couple of years.

3. The Software Development Option

While I was a senior in college, I attended a talk by David Bonderman, billionaire founder of TPG capital. In that talk he shared his views on the economy and broadly spoke about how much it has changed over the course of his career. I’ll never forget when he described the plight of middle-aged steel workers in the Midwest, and how he didn’t see their career options brightening any time soon. But then he added that “if you’re a twenty-something that knows how to code, the world is your oyster”. That phrase stuck with me long after I graduated and continued to nag me as I got into the professional world. My technical skills outside of excel were negligible—I had never taken a computer science course, and I could not explain to you how software, or even the internet worked. Two years of liberal arts studies combined with two years of business school had taught me a lot about economics, psychology, finance and history; but it left me with no “hard” skills. As I reflected how to form the best version of myself, I realized my skill set was unbalanced. Yes, I worked well in teams and communicated effectively. And yes, I was hard working, conscientious, and considered myself a quick learner. But I had no technical skills, and I would not find my optimal balance until I did.

I would be fine if I stayed outside the tech world, but that was the world that was making a difference and the world that I wanted to be a part of. Growing up I was always interested in technology. An avid gamer, I once bought a used computer from my town library and upgraded the graphics card and power supply so I could play my favorite games without having to use the family computer.

This realization made the last route, software development, a lot more interesting. Although the idea of building a version of myself that knew how to code was enticing, the road to get there seemed the hardest. Fortunately for me, my father was a great resource. His experience working in information technology was invaluable, and he suggested I look into coding bootcamps. Coding bootcamps are relatively short (usually three to four months-long) intensive programs that teach students practical job-ready technical skills. My father had earlier recommended coding bootcamps to my brother who had been struggling to find a suitable career. After completing the coding bootcamp my brother quickly found a job. I had nagging doubts his experience wouldn’t be relevant to me since my brother had taken computer science classes and generally showed an aptitude toward engineering. Nevertheless, having this anecdotal evidence that a coding bootcamp could result in a job was very persuasive.

Part II. The Path of the Software Developer—First Steps

After thoroughly researching coding schools and their job placement statistics, as well as having their curriculum’s reviewed by a software developer in my network, I settled on one, a four month program in Atlanta called DigitalCrafts. I chose Atlanta because of its burgeoning tech sector, my strong professional network there, and the lower cost of living. The program was a full-stack development course, which means it covered both frontend and backend software development. Frontend software development is the creation of interfaces for users to interact with, in this case websites. Backend development is about managing databases and building APIs, application programming interfaces, which are used by the frontend to display information. The program cost around $12,000 and claimed a job placement rate of 85% in related fields within six months of graduation. I shopped around and found this to be competitive among the other code schools I was speaking with. I applied, passed their screening process and elementary code challenge, and was accepted for enrollment. I submitted my down payment to reserve my spot in their June 2017 cohort and handed in my resignation letter at work.

In March of 2017 I began to fully dedicate myself to learning how to code. DigitalCrafts had supplied me a long list of resources and materials they expected students to complete before arrival and I began to work through that. The list consisted of a half dozen coding books and online lessons as well as a few other suggested materials. Now that I had taken the plunge into willful unemployment I fully committed myself to getting through all of the material. I set an alarm every morning and spent eight hours in my apartment’s community center, Monday through Friday, to get myself ready. I was determined to be one of the top students in my class and one of the first to get a job. This determination stemmed from both pride and necessity. I had left a prestigious well-paying position to pursue this goal, and I fully understood the opportunity cost of my decision. After modeling out my budget I also knew that spending six months after graduation looking for work would not be possible because I would run out of money. It was imperative that I find a job as quickly as possible.

1. Learning to Code

Learning to code proved to be a roller coaster of emotions. When you are first starting out it seems highly abstract. Learning to write a “for-loop” or an “if statement” without any context doesn’t seem valuable. Little do you know that these operations are essential. Syntax errors and bugs are extremely hard to detect for the untrained eye. Early material is dry and tedious. Progress is slow, especially when trying to teach yourself. When you have no idea why your code is not working, resolving these problems by yourself can take hours and sometimes days.

I estimate that it wasn’t until about two hundred hours into my learning that I started to get the hang of things and see the creative side to programming. Until I hit this threshold, the doubts about my decision had been mounting. I distinctly remember one night waking up terrified in a cold sweat, fearing that I had made a massive mistake, that I would look back on my decision and realize how stupid I was for attempting to learn to code. “People have been coding since they were teenagers”, I thought to myself, “what makes you think a twenty four year old just starting out will be successful”? It was not until much later that what I realized what I was suffering from is an incredibly common phenomenon called “imposter syndrome”. Imposter syndrome is common in many professions but seems to be especially ubiquitous among junior programmers. Imposter syndrome is the unshakable sense of doubt that comes with being inexperienced, and is accompanied by an irrational fear that you will be exposed as a fraud. Combining my struggles learning to code with the knowledge that I had abandoned a potentially seven figure salary job, to work on “for-loops” and “if statements,” my mental psyche took a beating.

After moving to Atlanta and arriving at the code school, much of the anguish caused by the imposter syndrome naturally dissipated. Although there were one or two people who had previous programming experience in my class, there were many who were clearly less prepared than I was. When a fellow student asked a question, there was a good chance I had the question too, so it was reassuring to be part of a group.

The coding bootcamp is where my learning took off. The biggest problem I had with my self-study was getting bogged down in problems that took me hours to resolve by myself. Now I had a knowledgeable teacher who could unstick me in a matter of minutes, so I could continue to move forward on projects or lessons. Our cohort began the curriculum by learning Python, which I had some familiarity with. Eventually we built up to creating a Python game, which you can find a link to here. We quickly moved on from that to more web-based technologies and for the remaining thirteen weeks of the class everything was taught in JavaScript.

What started out as a group of nineteen students winnowed down to fourteen by the midpoint of the class. Some had not completed the pre-work and were woefully unprepared for the pace of the class, others had personal issues come up where a full-time intensive school did not fit into their lives anymore. Regardless, the core of the class continued to move forward and group projects started being built that had tangible value. All of the pre-work learning “if statements” and “for-loops” had paid off as classmates and I built cool projects like cryptocurrency price dashboards, a heatmap of job openings for a given zip code, and an interactive chat room for teachers and students to collaborate.

2. My First Coding Job

At about the midway point in the class I began to apply for jobs. Having just left corporate America I wanted to work for a small company. Ideally I wanted to work for a startup because I wanted to have a lot of varied responsibilities, and I wanted to have a part in building a company from the ground up. I also knew that I didn’t want to work at a huge company in their back office programming group, rather I wanted to work at a company where technology was the core business.

With this framework in mind, I applied to startups in the surrounding area. To my surprise, getting responses as a developer was easier than I thought. Of course, the classic first-job catch-22 applied: employers wanted candidates with years of experience, while I needed to get my first year of experience. That being said, the demand for developers was much higher than I expected and I found myself interviewing for several junior developer roles before I had even graduated from the bootcamp.

One of the companies I interviewed with was a small group of recent Georgia Tech graduates who were working on building an AI to perform software testing. They had secured some funding in the form of grants from Georgia Tech and were part of a local startup accelerator program. Their technology stack fit what I was looking for and they had an immediate need for a developer to help them out on their front end. After a few video interviews and a final in-person meeting I was offered a job as a junior developer. I accepted.

With two weeks still left to go in the coding bootcamp, I was the second person in my cohort to get a job. I was thrilled. It was a huge relief to know the six months of worry and doubt that had plagued me leading up to this point were worth it. I graduated from the code school on October 17th, 2017 and began working the very next day. The bleeding from my savings account, which had been keeping me afloat, was finally stopped. While I still had a lot to learn, and the imposter syndrome would rear its head many times to come, I had my foot in the door and was getting paid to develop my technical skills.

Looking back, my decision to move into software development was a great one. I get to work on cool problems for fast moving companies, and my technical skills grow every day. While I knew I was going to make less than if I stayed a trader on Wall Street, the total compensation for developers is highly competitive against the broader job market. When I was considering leaving my trading job in early 2017, the career change initially seemed inconceivable. Only through an enormous amount of research and the help of a great network of family, friends, and professional connections was I able to gather the appropriate information to make an informed decision. If I hadn’t done such an extensive search of my available options, I might have crumbled under the pressure of my doubts. While this was only one chapter in my life, I hope to borrow lessons from this experience to use in the difficult career decisions that inevitably lay ahead.