Workflows For Developers

As you become more experienced as a software developer, much of improving your skill set becomes perfecting ‘workflows’. This concept is very common to professionals in other areas like graphics design, but I see it talked about much less often in software engineering. Viewing development from this perspective requires that you look at the multiple technologies, approaches, frameworks, tools, libraries, etc… as parts of an overall system. A properly constructed workflow should have ‘default’ solutions that answer the question “how do I handle this situation 90% of the time?”. Good workflows will minimize the time wasted considering options to implement ‘easy stuff’ and will make more time to focus on the real challenges and to build additional value into your solutions.

Implementing a workflow does not mean that you have to fully automate development or that you suck out all of the creativity or intelligence from the process. The value of a ‘good’ software engineer comes from the solutions you can provide to the 10% of system construction that does not fall within a standard workflow. But if you find yourself frequently having to stop and think about the various ways you can do something you probably don’t have your workflow sufficiently developed.

On the downside, coming up with a workflow that fits your approach to development will require a lot of time and effort minimizing all that you know to a core set. Here are some practical tips for speeding up the process:

1. Decide on a core set of development tools, libraries and frameworks. These tools should ideally incorporate a particular philosophy to solving problems that you should follow most of the time (for instance, using Angular and its approach to UI, only falling back to something like direct jQuery development when you need to do something Angular can’t handle). Once your pick a framework that matches your development preferences, resist the urge to stray away from the tool’s ‘standard approach’. Stepping out of your framework should be the exception.

2. Read books on patterns… all kinds of patterns. Avoid recreating the wheel.

Examples:

Analysis patterns: http://www.amazon.com/Object-Oriented-Analysis-Design-Applications-Edition/dp/020189551X/ref=sr_1_1?ie=UTF8&qid=1396199795&sr=8-1&keywords=object+analysis+and+design+booch

Database patterns: http://www.amazon.com/Data-Model-Resource-Book-Vol/dp/0470178450/ref=sr_1_3?ie=UTF8&qid=1396199857&sr=8-3&keywords=database+design+patterns

UI Patterns: http://www.amazon.com/Mobile-Design-Pattern-Gallery-Applications/dp/1449314325/ref=sr_1_2?ie=UTF8&qid=1396199881&sr=8-2&keywords=UI+patterns

3. Avoid “the new hotness”. You can evaluate new technologies as they mature to consider adopting them into your standard process, but modifying your workflow is time consuming and expensive and should be treated as a major step.

4. Minimize the time you spend considering options when you come to a point where you are not sure what solution is best. Remember, “There are no wrong or right answers, just more or less useful solutions”. It is sometimes better to make a decision and go with it than to spend excessive amounts of time agonizing over the options.

Bookmark the permalink.

Comments are closed