Click here to Skip to main content
13,904,766 members
Click here to Skip to main content
Add your own
alternative version

Tagged as



2 bookmarked
Posted 5 Sep 2013
Licenced CPOL

10 Realizations of Developing in a Business

, 5 Sep 2013
Rate this:
Please Sign up or sign in to vote.
A series of realizations (in no particular order) about working for a business and developing.
The great philosopher Heraclitus is most notably known by the phrase "Nothing endures but change." This phrase is more commonly known as "The only constant is change." If software development had subtitles, this phrase would accompany it to perfection. With the vast amount of changes to technology and languages, the non-technical lessons of development can get lost. As developers enter the work force, they quickly begin to realize being paid to do a job is different than programming as a hobby. These distinguishing characteristics separate the "work" development from the "book/school" programming. The following is a series of realizations (in no particular order) about working for a business and developing:
  • In most circumstances, it's the little things "done right" that make the difference. Achieving deadlines, completing code with minimal bugs, and releasing bug-free software help to raise confidence in outside stakeholders. Releasing 10 small enhancements without interruption versus one large distributive change always wins in the long run.
  • Saying "yes" to one thing means "no" to another. This might seem like a no-brainer but the second part is not always recognized. In business, time is money. Deciding to work on an enhancement or bug must consciously translate into the reality that it takes priority over other work.
  • Actively identify and accept feature/software obsolescence. From the moment a new technology or feature is released, the clock is ticking. It's important to be proactive toward this concept and plan accordingly. Microsoft is an example of a software company with a proven history of deprecating functionality and eliminating support over time.
  • Follow the "put in the big rocks first" approach. Do not shy away from the hard or difficult tasks in a project. Tackle those areas first. This will help identify problems early and provide better estimates for remaining work (as smaller items are easier to estimate).
  • With code and software features, separate the "gotta haves" from the "nice to haves." Most projects admittedly have both. Be pragmatic about the proper category for each item. As deadlines approach, this is invaluable for determining a minimally viable path.
  • In regards to feature requests, champion assimilation as much as possible. A big budget or lengthy project will raise the eyebrow of any executive. Start by accommodating the request within the current code and architecture. Consciously move beyond that only when absolutely necessary and actively over-communicate that decision.
  • Skills take years to harden, but mastering patience is a life-long journey. In a profession with broad opinions, varying personalities, and constant deadlines, being patient and mindful of others is paramount. Software development is about more than lines of code.
  • Do not discount or disrespect aspects of a job. Passing judgment on tasks can cloud opportunity. These include identifying areas of improvement, becoming a material expert, and expanding one's ability or knowledge on a given topic.
  • Never stop striving for "the right way." Many companies choose "right now" over the "right decision." Respecting that decision is important, but it should not impede continuous education about the risks involved. Developers are hired for their expertise as much as their ability.
  • Consciously revisit process, code, and functionality. Anything ignored will become the standard. Adopting concepts such as Agile and Lean development can help. Additionally, categorizing and tracking technical debt can improve visibility and provide points of discussion. 


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

You may also be interested in...

Comments and Discussions

-- There are no messages in this forum --
Permalink | Advertise | Privacy | Cookies | Terms of Use | Mobile
Web01 | 2.8.190306.1 | Last Updated 5 Sep 2013
Article Copyright 2013 by Zac Gery
Everything else Copyright © CodeProject, 1999-2019
Layout: fixed | fluid