How would you feel if you took your car in for an oil change, and when you got it back, the mechanic said: 鈥淚鈥檓 done with your car. I鈥檓 pretty sure you鈥檙e good to go.鈥�
Or what if you asked a cabinet maker to build you a custom shelf, and they showed up two weeks later at your front door with something like this.
鈥淕ee,鈥� you say, 鈥渋t looks fabulous, but I鈥檓 not sure how well it鈥檒l hold my set of winter tires in the garage.鈥�
Despite their best intentions, would you think you鈥檙e dealing with professionals, and would you think twice about dealing with them again?
Now think about your own work. Do these words ever come out of your mouth?
鈥淚 think I fixed that defect.鈥�
鈥淚 wrote the code for the feature; I鈥檓 pretty sure it works the way it鈥檚 supposed to.鈥�
鈥淚t鈥檚 in QA; they鈥檒l let me know if there are bugs.鈥�
If they do, it鈥檚 time to reflect on and objectively assess how you鈥檙e going about software development, the quality of the features you鈥檙e delivering, and your work ethic as a software engineer.
Whether you鈥檙e building something brand new, or working with code that鈥檚 been around for years, the software you work with day-to-day will evolve towards chaos unless good software engineering discipline is exercised, especially when a company is undergoing rapid growth.
Why? Because complex systems are, well, complex. And so are people, and how they communicate. Without applying the right mix of innovation, knowledge, skill and discipline, it鈥檚 far too easy for complex situations to organically evolve into a big mess. And it鈥檚 far harder () and more costly to fix a big mess than it is to prevent it from arising in the first place.
Are you working in an environment where some of the scenarios below are beginning to surface?
If so, you may be contributing to the problem.
As a , it鈥檚 your job to not only build the thing right (and jointly with your team ), but also to not contribute to the mess, following the to actively clean up around you as you go. Sometimes it means to questions that are clearly and profoundly conflicting with what are generally recognized as being at least decent engineering practices. This is why you spent several years of your life at a good university or college, why your employer is paying you good coin, and why you鈥檙e not working at McDonalds flipping burgers.
So what steps can you take to produce high quality features or bug fixes, and increase your credibility as a competent professional software engineer? Here are a few tips:
Don鈥檛 just dive right into design & and coding without properly understanding what the feature or defect entails. Ask questions, do the necessary analysis, understand stakeholder expectations, come up with a plan of action, and consider all the angles. If necessary, do some get a better perspective on potential uncertainties.
Without having a clear definition for your work鈥檚 state of completion, you鈥檒l continue to be guessing as to whether you鈥檙e really finished with the task. A well-articulated that will need to be met and demonstrated is key to shipping the feature or bug fix with confidence that it meets the necessary business requirements.
Whether or not you are doing Test Driven Development, having a great set of automated tests is essential not only to ensure your code works as expected, but to also safeguard it against defects that could be potentially introduced at a later date. Having and maintaining a great test suite helps keep product quality high, and helps engineers deal with the code with fearless competence.
Let鈥檚 face it, as a software engineer, the quality of your code is a direct reflection of the mastery of your development skills. If your , others are going to hate going near it, so please don鈥檛 subject people to that. Nobody expects you to be perfect, but you are expected to have solid software engineering fundamentals down pat, to want to improve, to learn from others (pair programming and/or code reviews are essential for this), and to avoid repeating the same mistakes.
You may think you鈥檝e written a great set of tests but prove it to yourself by actually running a code coverage tool and reviewing its results. Make sure the coverage percentage is as high as it needs to be for you to be confident that all the viable use cases have been addressed by at least one test. Since you shouldn鈥檛 have code for non-viable use cases, this means the code coverage should be pretty close to 100%! Be careful about not succumbing to the temptation to say: 鈥淲e鈥檙e at 80%鈥娾�斺�妕hat鈥檚 good enough鈥�. That 20% that you鈥檙e ignoring is what鈥檚 going to be keeping your team busy on evenings and weekends when your customers are down; because of that use case you hadn鈥檛 anticipated that your code isn鈥檛 equipped to handle correctly.
This should go without saying. If the tests don鈥檛 pass, no matter the reason, don鈥檛 release your code. 鈥淪ome of the tests aren鈥檛 mine鈥� or 鈥渢丑别 鈥�, you say鈥娾�斺�奿t doesn鈥檛 matter. If the tests are intended to cover use cases that your code handles (even if in part), make sure the tests work reliably. Broken, muted, or flaky tests are a clear indication that there is still uncertainty about whether your code actually works as expected or not.
Never surprise your stakeholders, at least not in a negative way. Following the tips above will give you a very high confidence that your work will meet expectations, but it鈥檚 always best to test your assumptions, so give your stakeholders a demo of the feature you built or the defect you fixed. It doesn鈥檛 have to be a long formal meeting; in fact, it鈥檚 best when it isn鈥檛. In addition to confirming that the work is , it also serves as a great opportunity to spread knowledge and receive praise/feedback that will help you and the team grow.
Learn more about how 糖心Vlog精品一区二区 can help your startup come to market through our Fractional CTO service, product development, and more. Visit /work-with-us.