Much has already been written and much will be written about James Damore and his “The Google Manifesto.” (I’ve also written about how organizations can mitigate and detect bias.) As for Damore, his screed is the kind of recycled garbage that has already been studied and refuted. It flies in the face of history and ignores the data right in front of Damore’s face. For writing this dammed illogical dribble, no developer has ever been more rightly fired.

Beyond the moral confusion Damore shows, he also doesn’t seem to actually understand engineering, as former Googler Yonatan Zunger wrote in a brilliant response to Damore’s manifesto. Zunger is right: Damore isn’t a good engineer or software developer. Software development is more than knowing what APIs to call or basic syntax.

So what exactly makes a good software developer? Here it is, in the kind of manifesto we should all be reading and taking to heart. I call it The Good Software Development Manifesto.

1. Believe in data

You may want to believe the system works or that you’re “better” than certain people, but you need to have data to support this idea. Most of all, you need to be willing to give up the idea if facts (or countless studies and history) prove that you’re wrong.

This means you need tests to prove your code works, and you need processes around your code that produce data that prove you’re not reverting code. Everything you do should produce data that lets you make further decisions. Otherwise, how do you know if you’re doing the right thing?

2. Software development is more than coding

Just like letter-writing is more than the words per minute you can type on a keyboard or knowing vocabulary and grammar, software development is more than coding. Software development beyond relatively simple things requires coordination, communication, analysis, design, testing, project management, and more.

Coding is important, but it is important in the way an engine is important in a car. The best software developers have empathy for others who have different roles, interests, and stresses on them.

3. Code is communication with people (or: Be social)

One of the first “languages” I learned was 8086 assembler. That was as close to the metal as I ever came. If we were really just “programming computers,” we would all be writing bytecode. Computers understand it best. But we’re writing in a “compromise” language that other people can understand and that can be translated to something the computer understands.

Good software development is a communication process. It’s about making sure people understand what you’re doing and why for that moment when you need a hand. Your job is to communicate with the next person reading it. Finding the best way to say it may require empathy.

4. Good processes are important

Conway’s law predicts that your software is doomed to reflect your team and its communication structures. Process is the structure of that communication.

Think of a plane taking off: You have a very structured conversation among the pilot, copilot, flight crew, and air traffic control. That ensures that everyone looks after critical issues and that everyone is heard. “Wings still attached to the plane?” “Check.” “No other plane in our way?” “Cleared for takeoff.”

5. You prove yourself with results, not “status”

The worst development organizations are either very hierarchical or have too many bosses per developer. That typically reflects a desire for status by being a manager.

Think “roles,” not “status.” The best organizations I’ve worked in recognize the people who made things happen first and foremost regardless of their role in the organization. (This recognition usually starts with whoever brought snacks, to be honest.)

6. Everyone can learn from everyone

If you believe that people’s ethnicity, gender, or whatever is a good way to judge their skills or what they have to teach you, you’re limiting your own development as a software developer.

7. Test all your assumptions—and be ready to change them

When mentoring young developers I always emphasize that you shouldn’t prove yourself right, but to prove yourself wrong. I also encouraged them to do it with the same gusto that they try to prove themselves right.

A logical theory tends to have a means by which you could be proven wrong. If it doesn’t, it probably isn’t a very good theory. If you can’t prove it wrong, then and only then maybe try and prove it right. This is a similar idea to “believe in data,” but it’s not just about the data but the means in which you use it.

This article is shared by www.itechscripts.com | A leading resource of inspired clone scripts. It offers hundreds of popular scripts that are used by thousands of small and medium enterprises.