Starting a new job is hard, especially when the job places you among some of the best in the field and the learning curve at times feels exponential.
There’s really only one word to describe how I felt starting my role as a Junior Software Developer at Frogslayer…nervous. I was coming in as a Texas A&M University student with zero experience creating large-scale software applications.
Luckily for me, Frogslayer has an intensive training program all juniors complete prior to beginning work on an actual project. I was expecting a technical deep dive into the specifics of the firm’s current projects. Those expectations, however, were shattered when I learned it would focus on creating good development habits and key professional skills.
Reflecting on my training, I can now say with confidence that this holistic focus provided me with lessons that I have kept with me throughout my year as a junior software developer. The technical knowledge would come in good time, but the foundation of best practices and good habits have been invaluable.
Here are my three biggest takeaways from software development training.
1. Manage Tasks Wisely
During the first week, I was presented with a graphic called the “Eisenhower Matrix.”
The principle behind this graphic is that if you find a task that is both urgent and important, it must be done immediately, while a task that is neither important nor urgent should be estimated and planned accordingly.
If a task is not urgent but important, it should be planned for the near future, while an urgent but not important task should be delegated if possible.
This matrix is a blueprint for prioritizing tasks that I’ve used frequently throughout my time as both a student and a junior software developer.
Oftentimes, as tasks pile up, it can become somewhat paralyzing to stare at a mountain of to-dos. This matrix has served as the map that allows me to manageably climb the ‘task mountain’ every time.
2. Write Effective Code
Another key lesson I learned while in training was how to write effective code. Prior to this I had thought the only metric which you could use to judge good code was the speed at which it ran or how few lines it took to write.
Through discussions with Justin, Senior Software Developer and Training Lead here at Frogslayer, I learned that the key to writing good code is writing code that is both easy to understand and written in the language of the domain.
Writing “clever” code is actually a huge negative, as it can make later developers who interact with the code greatly confused as to what the actual purpose of the code was.
Any given code snippet should be descriptive and clear enough so that someone looking at the code later can easily understand what that code was trying to do.
A good litmus test for this is looking back over your code and asking yourself if you could explain the purpose of the code snippet in a year, or if you can easily explain the code in plain English with little to no technical knowledge.
This brings me to the other key component of effective code: coding in the domain language.
Any written code has a product behind it that is being developed. As such, the naming of classes, functions, and variables should be explicit as to what they are trying to accomplish.
If a class function is being written that adds items to a shopping cart, then the function should be named something along the lines of “AddItemsToShoppingCard” rather than “AddObjectsToList,” even if the function on a technical level is simply taking two lists and adding one to the other.
These lessons about writing effective code were key to my success on a variety of projects, as my prior academic experience had mostly included writing simple scripts where there was little to no attention paid to the actual naming of variables, functions, and classes.
3. Communicate Quickly & Openly
Finally, during my time in training, I learned the importance of quick and open communication. I was encouraged to ask questions (no matter how “dumb” they might feel) whenever I got stuck.
As a developer, there have been plenty of times I’ve found myself stuck and needed to contact another developer or my tech lead for help.
I learned that if I have not made progress on a problem in over 30 minutes, then I should likely reach out for help so as to not waste time trying to find an answer that may be out of my current depth.
This emphasis on quick and open communication during training allowed for a very effective communication channel between more experienced developers and myself.
By setting this expectation during training, I never felt uncomfortable when I reached out about any blockers or questions I had.
Final Thoughts
The lessons I learned from the training I received prior to being put on a project provided me with a unique and pivotal set of skills that I’ll be able to take with me throughout the rest of my career.
Being taught how to prioritize tasks properly allowed me to balance my workload and personal life effectively.
Learning how to write effective code instilled in me good coding practices, which enabled my later success as a contributor to a variety of projects.
Understanding the importance of quick and open communication allowed me to feel comfortable in my role, knowing I had a great support network behind me, as well as grow in both skill and productivity.
While I was expecting technical deep dives and project overviews heading into training, upon reflection, it’s clear that I would not have been able to contribute as much as I have up to now without these key lessons.
I consider myself lucky to have begun my tenure as a software developer with training that transformed my nervousness into preparedness and left me feeling empowered to do my best work.
-
Anthony Matl
