To Learn, You Must Ship Your Code
To Learn, You Must Ship Your Code
The author feels that writing code that never sees the light of day will not help you learn.
Join the DZone community and get the full member experience.
Join For FreeIs the concept of adopting a continuous everything model a daunting task for your fast moving business? Read this whitepaper to break down and understand one of the key pillars of this model in Continuous Governance: The Guardrails for Continuous Everything.
When working on a project, the temptation is strong to make everything perfect before showing it to the world, or even just to your co-workers. You know each and every line of code you wrote, but you have a long list of bugs to fix and don’t want to expose your work until you’re completed everything that was on your TODO list. Shipping is scary, so you’re holding back with the excuse that you need to fix another bug before finishing.
If you want to make software people use and enjoy, and not just write code for the sake of it, you must get over yourself and ship! I’ve seen people holding onto code for ages, polishing it to perfection, only to leave the job before anyone had time to see the results and give valuable feedback.
The same goes if you wish to get feedback on code you’re doing as a side project. If you’re not shipping, nobody will be able to comment on your code and you won’t know if you’re going in the right direction. Agile methodologies have the right ideas about this. Getting used to shipping small changes will help you fight the urge to keep your code to yourself and having to push huge modifications at once because you’ve been playing it safe.
Also, we tend to underestimate the value of our software. A tool that will help improve business processes will be used and appreciated if it does the job, warts and all. When an application makes people’s work easier, they won’t mind putting up with some bugs for a while until you have time to fix them.
You want to validate with your users that you built the right thing as soon as possible, and there are many flaws you’ll see only when people are using your product. What if the incomplete feature you were planning to spend a few weeks on is not really needed? Better to know right away instead of sinking a lot of time into it.
The caveat is that you must allow time to go back and fix those problems when they’re found. On the other hand, you don’t want to fall victim to “ship the prototype” syndrome: if every time you show a quick and dirty prototype it ends up in production, you must make sure that what you show is solid and well-structured even if it’s incomplete. Shipping something is an important milestone, but it’s not the end of the project.
Are you looking for greater insight into your software development value stream? Check out this whitepaper: DevOps Performance: The Importance of Measuring Throughput and Stability to see how CloudBees DevOptics can give you the visibility to improve your continuous delivery process.
Like This Article? Read More From DZone
Published at DZone with permission of Cindy Potvin , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}