This content originally appeared on DEV Community and was authored by Erik W
In December, I completed my master's in software engineering. Ever since 2018, I have been juggling full time employment with being a full time student, and for the first time in 3 years, I had hours of free time I needed to fill.
An old colleague who owns a software consultancy reached out and asked if I wanted to fill those hours by helping out on some of their projects for a few hours a week. I gladly accepted.
The consultancy specializes in rescuing projects that have fast approaching deadlines for systems that are not progressing nearly as fast as they should be; a 911 for software projects if you will.
I spent the next three months with this consultancy, jumping into projects that were practically on fire, learning the existing system as quickly as possible, understanding the remaining requirements, and deploying features and fixes before the due date. Although I no longer work for the company (I am once again going back to school lol), I gained some valuable perspectives and learned a lot.
I want to share with you some of the most important things I learned.
Poor Design Will Come Back to Bite You
Many of the projects needed rescuing because the developer(s) originally hired to build the system either flaked, or the system evolved beyond a maintainable level of complexity. This isn't a knock against the developers, but a lot of times, when deadlines and doom are impending, good engineering practices get thrown out the window for something that works right now.
The problem is, poor design decisions don't just add to your problems, they multiply them. There were many times I thought the project I was working would have never caught on fire if the developers had added tests, adhered to SOLID principles, and remembered to keep it simple.
This of course doesn't seem realistic when you've got milestones to make in a certain amount of time, but for long-running projects, try to consider how much time you'll save your future self by taking time to think through and create well-designed classes instead of slapping together something that merely gets the job done. Also, consider factoring things like design and test time into your estimates and learn how to communicate the upside of these things to potential clients.
SVC, CI, and Automated Deployment are Huge Time Savers
First, I refuse to work on any paid project without some kind of software version control (SVC) in place, even if it's just on my local environment. Having a shared repository not only facilitates better collaboration with your teammates, but a well documented repo will save you hours in onboarding time. I cannot think of a single excuse to not have version control in place.
Side Note and Self Plug: If you'd like to learn git in professional-level detail, please checkout my (currently in-progress) git series here.
Secondly, if you can get a continuous integration (CI) server up and running with at least some basic smoke/sanity checks in place, you'll have a lot of confidence you wouldn't otherwise. In my 3 month stint as a consultant, I didn't work on a single project that had any tests, and that's scary as heck. An automated test suite is something of a safety net for catching simple errors and bad ideas you might overlook. It also can save you a lot of time doing time-consuming and tedious manual checks. Obviously, depending on the time crunch you're under, you might not always be able to get to 100% test coverage, but even 20% is way better than nothing.
Finally, automate as much of the deployment process as you can. Different organizations will have different requirements around when things are allowed to be deployed and so on, but the more you can automate, the better. Even if it's just a simple Bash or PowerShell script, the less you have to think about, the better. The longer you spend doing deployment tasks, the more chance you have of messing something up and taking down a production system.
PHP is Still Thriving
I lost track of how many projects I worked on during my short time, but they were literally all written in PHP. That's not to say PHP was the only language in the system, but it was a significant piece in each.
The reason I mention this is because PHP gets a lot of hate these days (and really, all the days that I can remember). That's fine but if that's a language you spent time learning, do not be discouraged, there is plenty of work for you out there.
This also reminds me of a point I've always pushed: language doesn't really matter. For every 100 show-stopping problems I come across, 1 is because of language while the other 99 are because of poor design decisions. Learning and practicing good engineering principles will take you much further than a specific language will.
Conclusion
I hope you enjoyed this article and it gave you some things to think about. I'm trying to get back into posting here more often so please keep a lookout for me and follow my new Twitter, @ErikWhiting4!
Let me know if there's anything specific you'd like me to write about too, I'm here to help :)
This content originally appeared on DEV Community and was authored by Erik W
Erik W | Sciencx (2021-04-07T19:54:14+00:00) Three Things I Learned from Moonlighting as a Software Engineering Consultant. Retrieved from https://www.scien.cx/2021/04/07/three-things-i-learned-from-moonlighting-as-a-software-engineering-consultant/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.