Attending a conference – how to mingle

Geeks are not known for their social skills. Which becomes very clear when a lot of them attend the same conference. I am currently attending the SharePoint 2012 Conference in Las Vegas and thought this would be suitable for all the geeks going to parties and mingles this week.

It is a list of 10 very concrete tips from a rhetorical and mingle expert. Very good tips, any geek following this will be successful (oh and yes, it works for picking up both men and woman as well 😉

Don’t miss this:

Rhetorical success is all about how to mingle, in the most efficient way. Mingle in reality. Mingle online. Mingle during parties and mingle in the office. It does not matter. You prepare your mingle in the same way as you – of course – prepare a text for publication. Ok?

 

Go to the ten tips here: Rhetorical success: How to mingle.

Sometimes it is business that needs to understand development

There is always that guy. The business oriented guy, the guy who can’t understand why a few lines of code can take a whole day to produce. The guy who believes that pair-programming is the equivalents to “get one pay for two”. This is a story about that guy and how I made him understand.

A few years back I was involved in in a project that had the attention of a vice president in a huge enterprise. The project had haltered and the VP’s response was to micro-manage developers tasks. One of the meetings I was asked to prepare was to explain why a switch in data access technology had to be done. A gruesome task: Explaining technology limitations to someone with absolutely no technology background. In the end it succeeded. Turning technology limitations into pure numbers: Bugs/LoC, Cost of a Bug, hours spent on performance tweaking, etc., etc.

But that is not what this post is about. This post is about how I got him to understand that developers are not glorified copy writers with the task of writing as many letters/day as possible:

– “I don’t understand? How can you only produce 100 lines of code in a full day? And that’s with two developers at the same keyboard!”

– “You write business plans right?

– “Yes.”

– “And how long is that document, about 30 pages?”

– “Yes?!”

-“I can write 30 pages of text in Word in a day, maybe half a day. How come it takes you weeks to produce the business plan?”

-“Isn’t that obvious? We need to figure out what the business plan is about, the text is just a documentation of our thinking.”

-“Exactly”.

From that point on there were no more discussions on lines of code, technical details or design/architectural decisions. From that point on it was only about features and velocity, process and predictability, and the most important feature of them all: delivery.

Is there any value in certifications?

The last few months there has been a massive amount of voices speaking out against any form of certifications. Today this was actualized in a twitter discussion with a Cornerstone (training company) and Emil Cardell. Emil argued that certifications basically are worthless and all you need is a little problem solving and google.

I’ve been working several years helping everything from individuals to large enterprises maximize and capitalize on the competency  they have and are reaching for. In this work I’ve come to realize that I do not agree with Emil’s simplistic view of the value of certifications, I find the issue more complex.

These are my thoughts on the subject.

Certifications outside our little sandbox

There are several areas where certifications are used outside of our industry, we are not unique. There are majors ones like doctors and electricians and minor ones like “transporting dangerous goods”. As with the certifications for devs, these will never single handily guarantee that the person holding it is competent; or even the right man for a specific task. But on the other hand, you would probably avoid letting a plumber without the right bathroom certifications rebuild it for you.

The classic example is people with drivers licenses, how many times have you wondered how they passed the test? But they still did, and you can’t drive a car without one.

So why do we rely on these certifications here but disregard them for software development?

State of today’s certifications

There is several types of certifications for software developers today and the major once can be categorize into three types that each have questions of validity raised against them;

  • Knowledge tests  (aka multiple questions / answers) – can be crammed.
  • Attendance (e.g. SCRUM Master) – Only measure attendance not knowledge.
  • Reviews (Arguing for a solution in front of a board like the MCA) – Risk being based on friendship or contacts.

Does these doubts make the certifications worthless? They will certainly make it hard to guarantee competency, but that’s not unique for “our” certifications.

So why the outcry against certifications in our industry?

Reasons of outcry

I’ve come across several, more or less well founded, opinions why certifications fail us. Some more admirable then others as well.

The “I’m better then you” mentality
This is based on the same feelings that people get from others driving their cars like mad men. The simple rhetorical question of “how did this guy get certified?”. The interesting thing is that there are millions of people that never judge people outside of their car, likewise it seems that when we start writing code, some start to judge others.

Simple criteria’s
Some criteria’s can be very simple to complete. So simple that the value of the certification itself can be questioned. “Should it really be enough to attend a two day course to get certified?”

“Everybody got one”
This ties in a little to the two earlier outcries, if everyone in the industry got one. What worth are they?

This is an objection I find very interesting, since no electrician can work without a certification. It’s not the fact that you hold one that’s the value, it’s that if you don’t, you shouldn’t work.

They are only on X, not on Y.
This is a very popular argument and it usually comes from people not agreeing that X is the technology to use, anyone competent uses Y! This arguments springs from the view that it’s “my way or the highway”, a view that almost brought down the ALT.NET movement completely. Is a certification on X worthless if it is X you will work with and not Y?

So is the value only in how “hard” they are to attain, how many people got them, or  what technology they are based on?

This is the real value.

The value of a certification always lies in the perception of the people it’s presented to. In our industry; MCP certifications held a huge value when they first where introduced. But as more people attained them, the perception of it’s value faded. There are still some that are well respected, most of them have few people that’s passed them. So it seems that we only value certifications as a proof of “superiority”, not as a measurement of basic knowledge in a job role.

I’d like to argue that there is value, even though it doesn’t prove your “superiority”. There is value from a lot of different perspectives.

Value for individuals

The Dreyfus model of skill acquisition speaks about 5 levels of competency. Going from one level to another needs different tools depending on where you are on the scale (Johan Normén will speak about this on devsum10). Today’s Certifications are such a tool.

It will not take you from competent to proficient or proficient to expert, but from beginner to advanced beginner. It’s often a measurement that you grasped the basics and are ready to move on. It forms a baseline for your claims to be competent.

And most importantly, it tells people that you put in the dedication and effort and those without the certification didn’t. It doesn’t tell that you are an expert but it tells a lot about who you are and what areas you studied.

Value for organizations

There is value beyond the individual in certifications. Organizations can use them as a tool in many aspects of their business model. They can be used to inventory competency, as a measurable goal for bonuses or as an argument for higher prices. For businesses the two strongest areas of use is first a mean for steering the business direction and secondly in relationship to their vendors.

Steering

If I as a corporate leader wanted to move my business in a certain direction I will have two challenges to handle. First I need to know where I am, I can’t plot a course without having a starting point, secondly I need to know that I got there. Depending what my ambitions are, certifications can help in either one.

Relationship

It’s easy to claim that you have 100 developers that know a certain vendors technology and is a strong candidate for partnership. But how do you prove it? A showcase isn’t enough, in theory everything in your showcase could’ve been produced by one person. Certifications are a great tool here. Since it’s neutral and not based on your own perception, vendors tend to trust certification numbers as an indication. It’s usually not all that’s needed, but it’s one component in a validation of your organizations worth to the vendor.

This need of a “neutral” verification is truly visible in many organizations job-ads as well. They wish for a “engineering degree” for their applicants, not because engineers by default make better developers, but because there has been a third party involved in validating your credentials according to a baseline that can be compared to others.

Do I think that certifications are ideal to achieve these two values? No, but it’s one tool, one step towards something that will be.

What does the future hold?

I don’t think we’ll see less certifications. I don’t think we’ll see “certifications” as a concept devolve in value. I think we’ll see different forms based on work and not solely on theoretical knowledge. I also think we’ll see better tools for organizations to get a solid overview of where they are. Does it mean that certifications as they are today will disappear? I don’t think so. They do fill a basic need, much like the theoretical test for your drivers license tell whether or not you are ready to do the “real test”.

I’ll tell you what I would like to see happening.

  • I hope that basic certifications get a little bit more unpredictable, so that pure cram session will require you to learn stuff (much like university tests).
  • I would like to see an apprenticeship form that has basic competency requirements and certifications and makes you a craftsman.
  • I would want for people to stop calling themselves “seniors” and instead work with their peers and earn the title “senior craftsman” not just print it on their business cards. This could be similar to how you gain your doctors hat in the universities.

We are working in a knowledge industry, we use our brain everyday to deliver our work. There will be a need to measure what we can do and there will be times that your individual competency has to be judge along side others. For us to be able to call our self a “profession” we don’t need less certifications, tests or titles. We need the ones we have and then some. We need to make a strong statement that Software Development is not for everyone, you need skills to call you a Developer. You need to understand that’s it’s serious work, not toying around with computers. Raising the bar with certifications, tests and titles will do that.

Excel as a software engineer, be a professional not an amateur

Jeff McArthur is a frequent blogger and tweets a lot. He’s one of those random (at least for me) guys you stumble across that writes good stuff you want to read.

During this weekend he’s put out a lot of tweets about the difference between a professional and an amateur. Most of them was in general terms and they all got me thinking. What do I think defines a professional software engineer? What is our profession all about?

Some label most of us technology geeks, and to some degree this is very true. I like technology. I like software and hardware and I play games. A typical description of a geek.

But is our profession only about technology? It plays a huge role indeed; technology is part of our toolbox. But is it all?

I would argue that technology is just a small part of what we need to do to be considered a professional. Here is my list, in no particular order:

  • Dedication – be dedicated towards delivering the BEST solution, not just A solution.
  • Continuously seek more knowledge – to be able to decide what is the best solution, you need to have a broad toolbox with a understanding and competence in many technologies, methods and tools.
  • Strive to deliver quality – not just quantity. A good piece of software doesn’t only do the job. It’s also reliable, stable and maintainable.
  • Pride – software engineering is a craftsmanship. You need to put pride in what you create.
  • Question your skills – at all times. There is always something to perfect, something to get a little better at.
  • Welcome feedback on your work – always look for opportunities to get your work criticized by everyone. Listen to it and change.

This seems to be oddly general. Being a professional in any trade means a lot of the above, but in our trade where business and technology moves faster then a high-speed train. We need to constantly be on our toes. Putting in an effort to learn, evolve and excel.  When we do that, we can start to count ourselves as professionals in the profession of Software Engineering.