10 Rules I’ve Learned, Broken, then Relearned As A Software Engineer

Well, my contract at Upsider is coming to a close and I am getting back on the job market. Upsider has been a fantastic first gig as a junior developer and I couldn’t have asked for a more warm, patient, and smart mentor as our founding engineer. He took me under his wing for my time with Upsider, giving me projects that initially I thought beyond my abilities and pairing with me routinely.

The projects I worked on covered the full stack (Upsider uses Rails) and began with more basic CSS/HTML re-tooling/building from specs, to adding test-coverage in Rspec/Capybara, to, eventually, taking ownership of an entire new messaging feature. I have learned a ton about working as part of a dev team collaborating with designers, product, and the rest of the company. I have tried, as coherently as possible, to synthesize all the lessons I have learned over the past several months into 10 Rules for Junior Developers who are starting out at their first gig. This list is by no means exhaustive.

1: Don’t Delete

Did you write that code? Are you implementing something to make that line of code obsolete? Cool, don’t delete it. It’s perceived as arrogant (unless you know 100% what it does and everywhere it touches the application and even then, I’d be wary.) I’ve accidentally done this several times and completely messed up not only styling throughout our app but also functionality (e.g. buttons no longer worked.)

2: Get Familiar With Codebase

I know you’re excited, I know it’s tempting because all you have to do is reposition a div, but get familiar with the codebase first. This will not only save you time in the future when finding things but will also decrease the chance of overwriting something or re-using a function name or class name.

3: Specificity

Be as specific as possible without being verbose. Does this button have a class name of ‘button’? Probably needs to be ‘sendCandidateEmailButton’. The result of specificity is quicker debugging for you as well as overall legibility for other developers. If there are certain naming conventions within the codebase, you should be following them. Previous devs worked hard to create a codebase that was clear, concise, and approachable. Be consistent.

4: Don’t Ask For Help/Ask For Help

This is misleading but an important lesson for junior devs to learn. There will be moments of panic in which you think you’re in way, way over your head. When you feel that you’ve hit a wall, try to remain positive and relish these moments: this is when your brain working, trying to figure things out, and when you are truly learning/improving. Follow these steps when you begin to struggle:

• take a step back and try to rethink the problem (I usually like to grab a coffee or take a walk around the block to clear my head)
• Google/Stack Overflow your issue (chances are someone else has had the exact same issue or something similar! Don’t reinvent the wheel!)
• Go to the documentation
• Once you have followed the above, feel free to chat with a team member about your issue but please don’t bug them about how to center a div or how to perform a nested ActiveRecord query.

5: Write A Test

This is pretty straightforward. There is no company nor organization I can think of that flouts their approach to software development as anti-TDD/BDD. Testing is an integral part of development and should not be an afterthought. This has the potential to cause issues to your immediate feature and the app as a whole down the road. Learn about the testing frameworks your company uses, look at how tests are written within the application, read the testing framework’s documentation, and then add test coverage for new features (don’t forget to test edge cases and for each conditional statement within the method!)

6: Learn Everything You Can About Git/Github

Or whatever Version Control your company is using. You don’t want to be working on the wrong branch or push to production accidentally. Having a solid grasp of Git is very important for developers so, if you aren’t comfortable, find some online resources to practice (https://www.codecademy.com/ has a good course covering the basics.) Commit often and rolling back will be much, much easier.

7: Focus On The Feature At Hand

It’s easy to lose sight of the immediate small piece of code you are writing especially if it is part of a larger feature. Remember: keep your code DRY and legible. If you find yourself getting overwhelmed, try to write some pseudocode to understand what exactly you are trying to do and what should fall under the purview of the current method you are working on. Starting out, I would frequently lose sight of the piece of code I was writing only to get a garbled mess of a method which didn’t really accomplish what I had set out to do. If you are writing a method to parse deeply nested JSON, go step by step and break up each piece into small chunks that don’t try to tackle too many problems at once (separate concerns if possible.) If you start to think about every possible scenario right off the bat, your code will become messy — worry about edge cases or handling other types of inputs later.

8: Don’t Write Bad Code Just To Get It Working

While learning to write code, I would constantly hear: ‘get it working, get it right, get it fast.’ This became my mantra in my first few weeks at Upsider. Yet, this strategy led me down the road of writing sub-optimal code with nested loops sometimes 3+ layers deep — not only was this slow, but it was also just wrong. There were many better ways to be doing this that didn’t involve 3 levels deep of iterations. My mentor pointed out that this often created more problems in the refactoring process (the ‘get it right’ stage) and made it nearly impossible to optimize without completely rewriting the methods. Though this is still a good process to follow, try to have clean/efficient code as an ongoing goal rather than end goal. This will make refactoring and optimization a heck of a lot easier, more straightforward, and less painful.

9: Learn How To Google

I would sometimes run into the ‘asking a question of the senior dev’-step too early when I hit a wall. This stemmed from the fact that I wasn’t googling properly. Usually, this had to do with being overly specific about my problem like ‘is it possible to use a Rails joins table to connect 3 models with different foreign ids?’ rather than checking Stack Overflow for, simply, ‘multiple foreign keys Rails.’ This may seem obvious at first glance, but in the moment you must assess whether your problem really is as specific as you are wording it or if it’s a broader issue.

10: Clearer Naming > A Million Comments

You don’t need a million lines of comments. I made this mistake on many a code challenge. Use comments sparingly where clarification is needed. In lieu of verbosity, use names that are specific and clear to another dev. Try to make your code as legible as possible. I’m often told that the best code should read almost like a language or a story. Part of this ties in to keeping your code DRY and separating concerns. Make things easier for yourself as well as for future developers looking at your work by using clear, concise, and specific naming.