February Developer’s Hangout : Are you a Professional?

As a follow up to the DDD Scotland open discussion session on Professional Software Development, this hangout was held to discuss the changes and challenges 2 years on. I’ve included a few notes below that made up the main talking points, and added links where appropriate for those looking for more information.

You can see my notes from the session on Google Docs : https://docs.google.com/document/d/1AbyvGJluSvndc7feAn_G0OhHpQ_W-F-y2zPXJpw2X2o/edit?usp=sharing
Or, for Evernote users : http://www.evernote.com/shard/s2/sh/f6df9b20-583b-4741-9387-68bd900e81d1/f96b05fd7285445eac2d51d2ca67cb7f

Requirements

Don’t ask the customer what they want – what they need to solve their problem isn’t necessarily what they ask for. Why do they need it? When do they need it?

Tom Gilb methodology – don’t tell developers what you want, tell them what problem they have and what benefit it provides.

Enhancing professionalism of a team

Different levels of professionalism depending on the level of the team, enforce standards when teams are cowboys and relax them as people get more experienced.

How do you bring professionalism to the team or to new members? Provide information and guidance. Define new practices. Tools such as JIRA, use of source control, tie commits into tasks and issues.

Phases : in a small team, pick the right people, and they set the culture. For existing teams, need stronger sticks to enforce behaviour, technical. Role models, training and mentoring.

Ethics

Public good : What is a universal public good? Depends on the country. Kill-bots are good for saving lives of US soldiers, but not so good for Afghanistan and Iraq citizens. Public interest disclosure – whistle-blowers. Responsible disclosure of exploits or data protection or other breaches. Do you close the hole first or notify first. Also thinking about data protection. Keep data in the right area to avoid DPA or Patriot Act breaches.

Don’t be evil. Don’t do anything illegal.

Professional Certification

US has a very different concept of “professional” from state to state. More like the Electronic Engineer chartership – CPD, maintaining quality, providing guarantees.

Health and engineering, been around for centuries. Being responsible if things go wrong. “I’m certified in a few things, and I’ve decided I don’t like it very much”. Defines those “in” and “out”. See “scrum masters” – disbarring people who don’t do things the way things should be. See lawyers in US getting disbarred for opposing the Vietnam War.

Software Craftmanship – principles and practices, a set of standards we agree to adhere to.

Saying no – if we can’t meet a deadline, say so. If something takes too long, make impact on deadlines clear. If you’re dependent on other systems, you’re very sensitive to them, and you have to adapt to them saying no.

Chartership – does that give your argument more weight? Does it help to build trust with the client?

International Competition

Not enough software developers! And a lot of them are contractors. Scouring the world for the best talent.

Finance doesn’t trust certain developers, particularly in other countries (outside EEA especially), but skills are improving everywhere.

Professional Behaviours

No ego – being gentle when criticising, removing ownership from code – owned by the team. Shared code ownership.

If you can’t keep up with the latest technology, or other CPD requirements, then you’re in the wrong profession.

SEMAT- Ivar Jacobson (UML) : make a kernel of “what is true about software engineering” that no-one can dispute. Dictating a flow of information between customer and BA and between BA and developer.

Hack Days

12-14th April : Learner Journey Data Jam

19-21st April : Mental Wellness Hack Weekend

 

Advertisement

Share this:

Here’s an interview I did with Enigma People about software as art and inspiring the next generation.

Enigma People Solutions

There’s no question that software development is a highly technical skill, but there has been a lot of discussion over whether or not it’s a form of art. While there is no real definition of ‘art’, the creation of something out of nothing comes pretty close. That’s software, so in turn, is software art?

As we’re not software developers ourselves, we felt that we couldn’t give insights as valid as the ones we consistently like to provide you. So we found people who could!

This week Craig Nicol, technologist at Amor Group, gives us his thoughts on the matter.

First, tell us about your involvement within software development.

I am a Technologist at Amor Group, leading large, cross-site teams covering multiple disciplines and technologies and I also blog and have presented at a number of conferences both on specific technologies, but also on the theory and practice of software development.

What originally got you interested…

View original post 662 more words

January Developer’s Hangout : Education, education, education

Thanks to those of you who turned up, good chat about becoming a STEM ambassador for Computer Science (see http://www.stemnet.org.uk/content/ambassadors/whoareambassadors for details) and about the stereotypes that put people off IT.

Is programming too hard or too boring? Are programmers are socially awkward anti-establishment hackers? Or are we all boring middle-aged men in suits?

That’s the perception outside the field, whereas we all know programmers are cool, interesting, social people. The question is, how do we make the next generation see it so they can join us, and help build whatever will follow the Internet?

The best answers we came up with all involved reaching out, whether that’s visiting schools or providing child-friendly events, and finding ways to get kids interested without bumping up against the stereotypes. Should we have hackday events? Do we need a Young Programmer of the Year competition where we can find and inspire teams to develop software and win a prize, take some regional heats and a national final? Or do we do things on a smaller scale?

So, do we tell people it’s problem solving? That’s ultimately the job, after all. Talk to people, understand their problems, and then build a solution. We use computers to do it, but the interest and complexity of the job is as much about the people and the processes we’re solving for as the tools we are using to do it. And if it’s problem solving, do we just need to find interesting problems to solve, whether it’s maze finding, or controlling robots, because robots are cool.

How much duty do we, as a community, and as a profession, have to find and nurture the next generation of developers and computer engineers?

Until next time, when Professionalism is the topic.