Inspiring web developers to have a sense of ownership and pride in their work is important

Wed, Jan 30, 2013 at 12:56AM

For a few years now, I have been shifting the strategy of my web design business to focus on automation and reducing the complexity of development so that we can stay competitive at a time when prices are lower and competition is more fierce.   Solving the problems which occur from having web developers as employees is something that I've still been unable to solve entirely.   Since I am a developer myself, I find it easier to do this work by myself.  

Increasingly, I wish to be able to collaborate with other developers.   I want people to notice the technical merits of my work and make meaningful recommendations for it.  However, I refuse to hire others if I can't provide a way for them to be effective and cover their own costs.  I'm barely able to pay my own way, so I don't want to be responsible for giving someone else a steady paycheck when I can't even guarantee one for myself.  

For now, I try to work with other companies until we've grown to support a large team.   Through these other companies, I plan to learn what is needed for success and then grow from that foundation of proven strategies.   I've learned with most relationships that it's important to learn how to compensate for how people behave, rather then try to make them behave differently. 

Proprietary work is just a job

A developer who is just an employee in a team that is told to build specific proprietary features for specific clients on a daily basis is not really achieving anything for themselves except a paycheck.  That paycheck can be larger at another company and if they haven't gained what they wanted as an employee, they may have very little loyalty in the long term.   It seems highly likely to me that developers like this will constantly be preparing for a move to a better job or to start their own business after a few years of getting burnt out.   As someone running a web design company, you need to be in a position that you are ready for that when it happens whether intentionally or unexpectedly.  

One great way to increase your employee's motivation

If salaried developers are instead allowed to build something they can reuse anywhere else, they are more likely to see a common interest in the work.  One of the easiest ways to do this is to make most of your programming done through free open source projects.   

Hiring experts is difficult

Many companies see attracting quality help with the proper training as one of the most difficult parts of business.   Many times it is the developer who provides the tools necessary for the business to function.   Their role is so critical that it may lead to inflated salaries and egos.  

Hire an "expert", but plan for average performance

Salaried developers may only be working for you as a shortcut for reducing the amount of things they need to worry about.  Maybe they aren't very talented with managing sales & marketing.   Someone who is a great programmer, however, has fully integrated the business and marketing strategy with their programming knowledge.  

As someone hiring a programmer, you kind of have to expect they aren't going to be "great".  You need to setup an environment where average people can succeed and feel useful.   You can easily find someone who talks all the lingo and sounds excited, but you won't know if they are really cost effective until extensive time and money has been spent to bring them up to speed.   So you need to plan for them to only perform at the "average" level, and not the expert level.

Realistic expectations combined with more employee focused business model

People who are inspired may go home and find ways to improve your business for fun.  Employees who contribute their free time and daydreaming to help you grow are able to make a profound impact on the company.   Consider that most of Google's most successful projects were born out of their 20% time (Employees receive 1 day per week to develop projects they are interested in for the company).  Projects like, google earth and are considered to be born out of 20% time.  Those projects have since changed the world.

Inspiration reinforces the desire to do quality work

Being paid to do what you want to do instead of what you have to do is a big deal.   I know I quickly lose productivity once I have to switch to a project that I am not interested in.   I think most web developers would like to think they are doing what they love, but the reality is too often that they are just trying to get paid and maybe have 10% of their time to do what they love.    Too many companies are closed source and building poor quality applications that no one inside the company or outside the company really care about or use.   

Putting your code in the spotlight (open source) and collaborating with others better forces you to stop doing things the wrong way and learn more.  It helps to elevate your craft, while at the same time making it easier to see where you have trouble.  If no one is adopt your open source project or they have a lot of trouble with it, it is likely that you have trouble with it within your own company too.  Perhaps a lack of documentations, tests and organization are causing more waste then you might realize.  With making the code open source, you have to be more concerned about security, code quality and other issues then with a proprietary project.

Security, stability and brand reputation

There is a such a thing as "security through obscurity", which implies that your application only seems secure because no one has discovered the serious security flaws it has.  You've hidden them away in some unexpected way, similar to sweeping the dirt under the rug to give the appearance of security.  The same could be said for bugs.  The lack of validation and load testing could lead to serious bugs in production even though the application seemed to work when tested for its expected behavior.  Security issues and bugs will be fixed more quickly when other users are affected since it can more quickly destroy the reputation of your project.   When you can no longer hide your problems, you will feel more responsible.  

Having a few people outside the company urging you to make improvements could be a really useful tool for setting priorities and bringing awareness to technical issues.   If dozens of people report similar issues with the software, it will be clear that something should be done about that.   Management will see preserving their reputation as a serious business issue and this will lead to a better technical direction where technical issues are considered in more detail instead of the mad rush to knock out new features.  

Most people have the opinion that open source projects are typically more secure especially over time, since the number of people looking through the code will be substantially higher then what you can afford to do within your own small business.  Having a popular open source project  gives you a worldwide quality assurance team for free.   These benefits alone could justify making the code open source.

What else can be done to inspire developers?

Maybe you've adopted a open source development mindset with employee focused business model, but things are still a mess and people are losing faith in their work and the company?

Encourage them to learn how to write better code

In many ways programming is still too new for there to be any certainty about how things must be done, but there are schools of thought that have laid out an excellent foundation on improving the software development process.   A book called "clean code"  was written by Robert Cecil Martin in 2008 and it is going to leave a lasting impact on the way I write code in any language even though I've already read numerous books for many languages and been programming for over 10 years.   Robert is the early leader of the Agile software development  methodology which set out to replace the slow, inefficient traditional software development process with something more rapid and effective.  Years later, the data shows that Agile is truly an improvement and most developers have a familiarity with Agile, but may not have fully implemented it yet.  Agile started over 10 years ago, but Robert's more recent writing is further clarifying the points that Agile set out to make and it really brings makes it easy to understand how developers should be writing applications.  

Make better priorities starting at the management level

One of the biggest points the book makes is that it is unprofessional to stop working on your code at the moment it functions correctly.   An application that simply works is far from its ideal state.   It may be an unorganized mess with numerous difficulties that will occur later when the project grows.   A manager who demands for a rush job on a project on a frequent basis is destroying the productivity company in the long run.  

Management should learn more about programming methodologies

It should be just as important for the management to learn what Agile is about, and not just expect programmers to do the right thing.   Management needs to create an environment that encourages a consistent and effective work-flow.  The book says that most projects are in a constant state of repair and the more that can be done to make maintenance faster, the more "Agile" your development process will become.   A key part of all this is for you to implement as much automated testing as possible, but in addition to that the book describes in great technical detail how to write code that is easier to understand assuming that you already know the basics of Agile Software Development and especially Test Driven Development.   

Allow problems to occur and learn from them

Looking back at most of my work in the past, I have done many things wrong.  It will take me years to improve this and to further my understanding of Agile and other programming concepts.  It is likely that your team will not get it right the first time.  You have to expect this and still encourage it to continue to evolve.  After a period of refinement, the most elegant design will reveal itself.  I feel like the book really sets the bar very high - perhaps too high.   Too high because it may be impractical to immediately jump straight to the most elegant solution.  It takes many smaller steps of refinement over a longer period of time.   Mix this difficulty with fast paced business priorities and it can be quite hard to follow the Agile discipline strictly, but it should be always be recognized when a shortcut has been made, and an attempt to return to the stricter discipline should be made eventually.

No matter how senior your team, it is likely they can still learn more.

Google engineers often say how they were known to be experts at their previous job, but are often quite low in the pack once getting to Google.  Despite doing this work and trying to improve my craft for over 10 years, I still learned a great deal from the "Clean Code" book.  It has taught me more about BETTER programming then anything else I've ever read.   I recommend that any developer who considers themselves "good" or "expert" level to read the book.  If this information was applied over the next few years in your work, it is likely to have a noticeable positive impact on the projects and companies affected.

Smarter people may be accidentally making things worse

Smarter people have all kinds of bad habits that make you have to think way too hard about the code.  The smarter you are, the more likely you aren't even noticing how cryptic you are being.  "Clean code" is more about helping less smart people not be encumbered by smart people.   Management should frequently encourage code reviews that attempt to measure how well the project is progressing in terms of organization and tests. The difficulty of understanding what you've done just gets exponentially worse by the time the project grows large enough to be truly useful software.   It may seem all exciting to have new features rapidly in year 1, but then in year 2, you have 50% as much productivity and a lot of people start thinking "we need to rewrite", "we should start over", "we need a different framework",  "we need our own framework", "we need a different language", but it's probably that they did everything in a rush without considering the long term impact of doing that.     

The book makes the example of a patient who asks that doctor not to wash their hands because they need to be helped immediately.   It is the doctor's responsibility to tell the patient no.   It is similar with programming.  The management must be told that there are serious implications which will infect the company if they go unchallenged.

Researchers have found that the Agile approach is impressively more successful

People have have done thorough studies of large and small organizations that apply the Agile Software Development approach compared with traditional approaches.  I invite you to browse through some of them on google.

From my research, I have found they always find Agile increases project success and reduces cost compared to traditional approaches.   The traditional approach is typically better then what we do even, so there is a lot that many web developers just never find time to do.   It's taken me a lot of time to improve and automate my business enough to be thinking about this again.   It is easy to understand how to improve applications and companies, but far more challenging to execute those changes.  Likewise, delivering new features is easy, but delivering an open source project that other people can understand is insanely difficult.

Bookmark & Share