Categories:
Tags:
Unfortunately, I was recently laid off by my former employer, Revature. I worked there for over 6 years, and I wanted to take some time to reflect on my time there. I started as a junior Java developer, progressed into QA and test automation, and ultimately a manager position doing QA for our training programs. I learned so much from my trainer, my fellow trainees, and later my coworkers and managers. There’s plenty of technical details I could cover about my time there, but I wanted to focus on the higher-level concepts about software development.
I realized in my first year that no developer knows everything. There’s always something new to learn, and that’s okay. Good developers don’t necessarily write all code from scratch. They know how to find the right tools, libraries, and APIs to help them. Why reinvent the wheel when there are dozens of different pre-made wheels to choose from? Of course, it’s good to know how wheels are made, but when constructing a car, it’s faster and cheaper to get wheels off the shelf.
Another important lesson I learned was the importance of testing. I’ve often times started a project, only to get stuck for hours tracking down bugs that would have been easily identified with unit tests. It’s much easier to fix a bug when you know exactly where it is. Writing tests also helps you understand your code better. It forces you to think about how your code should behave in different situations. It also helps you catch bugs early, before they become bigger problems.
Communication skills are probably not the first skills one associates with developers, but it is a definite prerequisite to writing clean and maintainable code. Clear documentation and comments can save you hours of time later on. It’s also important to be able to explain your code to others. You might be the only one working on a project now, but that could change in the future. If you can’t explain your code to someone else, how can you expect them to maintain it? Even for solo projects, it’s easy to forget how your own code works later on. Writing good documentation can help you remember why you took that clever approach you came up with 6 months ago.
Lastly, I learned that there is much more to software development than just writing code. It’s about working with others to solve problems, from beginning to end of the development lifecycle. Understanding requirements and constraints is critical. A mistake early on in the design process can be more costly than a mistake in the implementation, and it leads to more wasted effort. That’s why it’s important to get feedback early and often. It’s better to find out you’re on the wrong track after a week of work than after a month.
Besides software development, I also had a front row seat to how a programming curriculum is delivered and how new programmers and developers learn. Everyone learns differently, but learning by doing is a core requirement of nearly every training we ran. You can read articles, watch videos, and listen to tutorials, but you won’t truly understand a concept until you’ve applied it or built something with it yourself. You have to make mistakes and learn from them. This is the most frustrating part of learning to code, but it’s also the most rewarding.
When I started my career I was intimidated by the sheer amount of information I needed to learn, and not knowing what I should be focused on. But I’ve realized you don’t need to know everything to start building things. You can learn as you go. You can build a project with the knowledge you have now, and then learn new things as you need them. You’ll learn faster and retain more information if you’re applying it to a project you care about. So for anyone who is just starting out, don’t worry about knowing everything. Just start building.