Software Engineer Code of Professional Conduct

ACM Code of Ethics and Professional Conduct

Software Engineer: Phases of Professional Development

Software Engineer Developmental Rubric

Dimension	Jr. Technician	Mid Carrier Level	Team Leader	Architect
Training	Learns job requirements	Teaches requirements	Teaches Technical Concepts	Disseminates cultural values
Operating Procedures	Told what to do	Standard Operating Procedure	Best Practices	Patterns and Practices
Standards	Writes code, waits for others to test	Test functionality, will settle for working functionality	Oversees build, replaces work that is substandard	Creates implementations of concepts
Requirements	Only works on requirements that are supplied.	Gets requirements from stakeholders	Integrates stakeholder requirements with scope	Integrates requirements, scope with systems architecture and corporate vision. Sets Technical Vision
Vision	Disregards vision, too distracting, too many other things to worry about	Disregards Vision, believes it is just another stupid HR initiative	Uses vision to generate excitement.	Set vision goals to expand the software community ecosystem and incorporates altruistic agenda.
Value System	does not know	personal ethics	team ethics	community ethics
Relationship between Effort and Result	Believes others are "smarter"	Believes excuses, if only everyone else would do something then this would work.	Takes responsibility for outgoing work.	Integrates contemplation of software concepts into leisure activities. Incorporates professional growth into Personal learning and private conversations.
Programming Style	In line	some encapsulation	class hierarchies	Asyncronism processing, prototyping, Interface building
Testing	Expects others to test	Ad-Hoc Testing	Testing Against use cases	Automated Testing Suites

ref: Appendix A: Memetic system for the historical development of developmental research; Dr.D.K.Dirlam

Software Engineering Culture, Shared Cultural Traits

I have given some thought to traits that are common within individuals in the software culture.

Common Cultural Properties:

• Describes learning as exciting
• Caution - Pessimism
• Long Work Hours/Personal Responsibility - Doing anything it takes to get the job done.
• Strong Personal Sovereignty
• Anal - Process oriented
• Oriented towards knowledge acquisition
• Prone towards empirical experimentation
• Skeptical - proofs require measurable result

It is easy to see that when asking a knowledge worker if “learning is exciting?” All will know the only acceptable answer is yes. Not only would their peers would make fun of them (peer pressure?), but ansering in the negative during an interview will most likely cost you the job.

The cautious streak comes from the fact that we work in environments filled with possible problems with implications that can get us fired. If someone foolishly destroys the database server and all staff and all customers are not able to perform work related functions for days, there can be quite severe repercussions. We learn caution from getting burned a couple of times.

On project deadlines we all ramp up towards the end, crashing project timelines, leading us to trying to get things finished by the imposed timeline, which does not represent the amount of work that needed to be done, but the desired time to finish the work. We get used to very heavy workloads, and very late evenings. Most of us develop mitigation strategies like “work from home, ” to offset this. Even still it is common to work until 2am at least 5 times a year, in even the most relaxed environments.

I think a large part of the personal sovereignty comes from the monetization of the software engineer skill set. The negotiating leverage is useful far beyond acquiring money and benefits. After a knowledge worker achieves their financial goals, they can use this leverage to have a say in the development of the environment they work in.

Software engineers are process oriented as a group. The work attracts Type-A people and rewards “anal” behavior.

Knowledge acquisition is rewarded in our culture with more money, and career advancement, this positive re-enforcement causes this trait to be common amongst member of the knowledge worker community.

When dealing with complex problems that need to be solved I have heard, “when the going gets tough, the tough get empirical.” To ascertain the root cause of a wickedly complex issue (a quandary all software engineers find themselves in) empirical methods to test hypothesis is a necessary debugging tool.

Our skepticism and desire for measurable truths results from the relationship software engineers have with the business. In bad environments (you know we have all been in them) we work with the subjective emotional experience of “The Business” and try to convert that to testable rubrics and machine instructions.

Software Engineering Culture, a little background

The knowledge worker culture as we know it today began with the acceptance of the UNIX (AT&T) operating system in the 1980’s. The software language C⁽¹⁾ that was built to run the UNIX environment is the root of our modern systems.

In the late 1980’s modern database systems were completed, and added support for a common extraction language (Structured Query Language, SEQUEL developed by IBM) and support for Open Database Connectivity (developed by Microsoft) was added in the very early 1990’s. OS2, a joint project of IBM and Microsoft, which morphed into the Window NT family was started in the late 1980’s and released in 1993 was the final fundamental step that completed the move to the modern computer era. By 1995, with protocols like TCPIP, HTTP, OLE we had a platform that significantly resembles the modern age of software.

Most of the people that I know in the industry spent 1989 through 1996 developing data retrieval code for Windowed based GUIs. From 1996 to about 2001, 2002 the industry scrambled to implement web sites and web applications, with out much knowledge about their tool sets. So from 2002 to today, we have been cleaning up the mess we made in the late 1990’s.

So when people talk about the pace of change in software, I am taken aback. We have had two decades to get used to the current environment. The last big change in the industry came with Microsoft’s release of the .NET framework in 2001(we'll talk about SOA later, it came before this, and does have a large paradigm shift grade impact), and that was a shift that took the code base back to the Object Oriented Programming Ideals⁽²⁾ of C. What .Net represented was not so much a rethinking of software, but a nanny system that forced bad programmers to correspond to established best practices.

The problem with having an idea of the changes in software is that the code changes from year to year, as better version (revisions) of software are released, not that the paradigm of development has changed. Add the fact that computer systems have immensely complexity, to this and it could appear that every thing has changed, when we are only discovering what we did not know last year (but really should have).

So, that almost unanimous statement that “Change” is part of IT culture is something that I always wince at, when I hear it. The only universal changing thing in IT is knowledge-workers abandoning their respective employers for better opportunities.

So what is the Zeitgeist of IT Culture, what are the traits that we share? Unfortunately I will need to weed out those people who write code as only their job, and talk only about Software Engineering Culture.

• Need for constant process improvement. “If I am not improving things here, I can just go somewhere else that I can make a difference.”
  
• Control over their own personal sovereignty. “If you don’t like it, I can just leave.”
  
• Aggressive negotiating skills. “I got five hits today on my monster resume.”
  
• Need to achieve to their own level of quality. “You don’t own quality, we all do.”
  
• Aggressive self-study program. “I will implement that new third party software in three days, I will learn it on the fly.”
  
• Consistent desire to implement new ideas. “Check out this recursive function I made!”
  
• Desire for a comprehensive solution to problems. “We need to fix the underlying problem, not just patch the patch.”
  

⁽¹⁾. C was a class based language with support for functions, it spawned C+, C++, and Java and is the basis for Microsoft.NET
⁽²⁾. With some very cool API features and Visual Studio 2008 has a great code editor, but it still is a direct descendant of C.

Learning Culture in Software Engineering - Preamble

So I have been at this for over two decades now, and have been close to software development for 26 years. During that time, I notice a pattern, which has been 100% accurate. All software engineers who are very good at their job are dedicate to life long learning. They all have a robust self-study program that they control, and allows then to master new ideas.

Often they are mistakenly thought of by others as being smarter. But in truth, they are simply diligently working a self-study program.

A self-study program is important because it trains the software engineer in acquiring new information quickly. It helps train the individual in the art of making informed assumptions that speed up knowledge acquisition. It shows the individual the size of knowledge chunks that they can consume, and through repetition trains them to be able to absorb larger information groups. The self in self study is important because it trains the individual in being able to go after information and knowledge on the individual’s own time and to correspond to the individuals life flow.

So if one believes that repetition leads to enhanced skill uptake, then following a self-study program would improve an individuals overall learning capacity.

Learning and being smart are core culture traits of the IT industry. This culture of learning in IT is nourished by Higher Education Establishments, Large Software Venders and by individual engineers. It is a common thread amongst all knowledge workers.

So we will want to look at this cultural trait a bit to understand it.
How do you foster and grow a culture of “life-long” learning?

• How does “life-long” learning benefit you personally?
• What value does “life-long” learning bring to organizational structures?
• How is “life-long” learning taught and passed on to incoming members of the community?
• Who makes their resources freely available and what benefits does that bring?
• Where does “life-long education” fit into “life-long learning?”