Categories
development programming

Somebody else’s problem

Sometimes dividing tasks creates inefficiency. When one person both cooks and cleans, they tend to create less washing up than if the tasks are divided, because washing becomes “somebody else’s problem”. However, when one person washes and the other dries, the load is equivalent. This setup can be prone to stoppages when the drainer is empty and the washer is trying to get that stubborn burnt bit off the pan, at which point any good ToC practitioner will ask the drier-upper to help with the washing to maintain throughput.

When teams are divided by layer instead of features, the interface between them becomes a fracture because each team has context missing from the other. Data has the wrong shape, validation requires fields that can’t be captured. If you build both sides, the transition is smooth.

When developers test, they can focus on smaller, independent chunks, which means fewer tests with greater coverage. Writing integration tests for complex calculations is painful and slow. Testing those same calculations as an xUnit Theory is cleaner and faster.

Specialists are great, but where is specialisation causing fractures and more work?

Categories
development

How do you know when it’s time to move job?

Around 18 months ago, I decided I needed a new job. It took almost 8 months to find my current job, and I swayed between wanting to leave and wanting to stay. In the end I discovered that I was finding excuses to stay because I’d been there long enough, and made enough friends, to be scared of leaving. But the company I left was a very different company to the one I joined.

If you’re starting the new year after some time off, starting to fear going back, or having doubts about your job, have a think about these things, and see where you stand. Then decide if you want to stick or shift.

Some of these are things I’ve felt, others are ones that came up from multiple people in recruitment interviews I’ve done over the last few years.

  • You don’t see yourself here in 5 years
  • You have more direction than your company
  • You’ve lost sight of, or respect for, the company values
  • You do all your learning, and all your best work, out of the office
  • The idea of doing the same thing next year fill you with dread. But it’s exactly what you expect
  • You’re ready for the next step, but you can’t see where that step is.
  • Your team, or your company, is shrinking, and no plans for growth are forthcoming.

What’s made you switch jobs?

Categories
development leadership

How to mentor 

​Once you start getting experience, you’ll find other developers asking for your help. I started tutoring at university so that I could help, and reflect and improve my own knowledge. 

Mentoring isn’t about answers. It’s about learning how to find the answer. The most interesting problems we deal with are the ones that no-one knows how to do. 

When someone asks for help, help them to help themselves. You need to start asking questions to help them find their own way. 

A successful mentor makes themselves obsolete quickly, but remains available to keep asking questions. A successful mentoring process leaves the learner with autonomy and support. 

My favourite quote from my tutoring days was a pair who, after I asked them enough questions to finish the tasks, said “I like you because you make me feel smart”. 

If you’re hiring the right people, they will be smart. Make sure the mentoring and onboarding reforces that. Smart, confident people are the ones who solve problems. 

Categories
code development

CodeCraftConf take-aways

I’ll let the other guides at CodeCraftConf summarise their talks if they wish, but here’s a few quick takeaways that I want to record.

Simplicity

Simplicity is always good to strive for, but the most interesting question for me is how to tell when code is not simple enough.

It happens when we get frustrated, and swear, when we start to experience cognitive drag when trying to understand what it does.

Cloud

Nothing is secure (just ask anyone who’s filled out the PCI compliance questionnaire)

Lean coffee

Alignment is the most important thing to get out of meetings.

2 backlogs – how do we capture the idea that not everything on the backlog is equal? Maybe you need a “ready to start” definition as well as a “definition of done. Maybe you need a “we’ll definitely complete this sprint” vs “we’ll look at these next”, or maybe you just need to read Warren Buffet talking about focus.

 

CitizenM is a big improvement over last year in terms of noise levels.

Categories
code development programming

Usable APIs follow-up

Following the Usable APIs guided conversation at CodeCraftConf, I wanted to capture some of the thoughts that came out.

Starting an API (as a user or a developer)

  • Does the API documentation include examples of usage (i.e. have they thought about the client)
  • How mature is the API?
  • How well maintained is it?
  • How long does it take to get to the first success (e.g. 200 OK – assuming success doesn’t mean error).
  • What’s the versioning policy?
  • What’s the contract?
  • What’s the shape of the data?

Changing and retiring APIs

  • Never, ever, ever, change the endpoint.
  • Give as much notice as possible of changes (and never negative notice).
  • Provide migration guides to clients, or automation scripts, such as the Python 2to3 migration scripts and guide.
  • Be proactive – there was an example given of a web API (I can’t remember which one, sorry) that changed their endpoint, and created a bot that searched Github for usages of the old URL, and submitted pull requests for the new usage.
  • Deprecate, then kill, once usage falls below a threshold.

Foolproof APIs

Isolation and proxies

  • Log everything to detect unreliability.
  • Make sure proxies are kept up to date with the underlying API, and fail gracefully when the API changes.
  • Expect failure.
  • Data is key – don’t give up more than you have to.
  • Make sure, as a server writer you understand the client, and the network.
Categories
development

What is an agile developer?

A developer who practices continuous improvement, with or without the support of an agile team.

You care about being better. You consider code to be craft. You’re only happy when you deliver value, so you want to deliver value more often. You set yourself a high bar, and always try to raise it. You want to learn. 

You accept your mistakes and move on. 

What does an agile developer mean to you? 

For those of you coming to CodeCraftConf, I’ll see you on Friday. 

Categories
development leadership

Bad change : The rock star developer and dealing with unexpected change

Have you ever worked with a developer who knows everything? The one who does a bit of tinkering in the evenings and weekends, and when the rest of the team come in, they can’t find anything in the code?

Yes, it’s a bit neater, but it’s a lot more broken, because it’s less readable, because it’s using a beta version of a library rather than the previous stable version. And one project in the solution uses different conventions to the rest.

I also tend to find the tinkered code is proof of concept with minimal testing, and little documentation. So the software diva who developed to the limit of their ability can’t tell you how it works 1 week later. They got bored and moved on. After all, there’s another Javascript framework to learn.

It’s great if you write throwaway code. If no project lasts more than a month. But that’s not the software I’ve been building. I enjoy the challenge of nurturing code that’s got a lifespan of 5, 10, 25 years or more. Not necessarily the same code, modules get rewritten, tests get added, dead code is removed, but it has to remain readable and maintainable all the time.

If you are a lead with a diva on your team, use them for research, because they will chase The Precious whenever something shiny comes into view. But when they need to get code into production, enforce your coding standards strictly. They will moan. They will sometimes throw a tantrum. If they do, you know they’re wrong, otherwise they’d have a convincing argument for doing it their way.

Standards are universal. Divas are occasionally useful idiots. Learn to spot them, and use them to your advantage without disrupting the rest of the team.

Categories
development programming ux

Developers are Users Too : Why the User Experience of Your API sucks #yourapisucks

Many thanks to those of you who came along to my talk on why your API sucks. There were some great discussions during and after, and I hope I’ll be seeing slightly fewer reasons to tear my hair out in the near future.

A few things that people mentioned that I want to discuss again, as they’re not on the slides.

APIs still need a view model

There was a question about the API view of your data vs the database view. A good API still follows MVC principles. Just because a View is written in JSON instead of HTML doesn’t make it a model. Isolate it, because otherwise a database change is an API change. You can use automappers to save you having to write convertors, but always create a view for your API so you can handle versions and create consistency.

There was also a big discussion on how deep the hierarchy should be, particularly relating to data obesity. And it’s a different tradeoff if you’re optimising for poor latency, where larger packets with redundant informatio make more sense, or timeliness where small packets that can be built and parsed quickly are preferred. It all depends on your users. It may be the case, as the Trello API does, that returning the deep hierarchy is a request option so that the user can decide.

User Experience doesn’t always mean asking the user

Developers will ask for lots of things that aren’t useful. Sometimes you need to discover what the user needs are. Maybe it’s a test-first design. Maybe it’s a loosely typed API to help you discover what users want to do (think Google search vs Yahoo’s hierarchy – Google is more loosely types so was more likely to return odd results, but Google had lots of data on what people were searching for that it could learn from).

Link suggestions from the audience

Thanks for these suggestions. I’ll have to try them out myself, so I’m putting them here without warranty.

Kong – to consolidate your APIs, and create the polished surface that doesn’t expose the dirty, inconsistent history behind it.

RAML – to design a typed RESTful API up front so you know what it will look like.

Heroku’s HTTP API design guide

Slides from Google Docs

Developers are users too

Slides from Slideshare

Categories
development

Fear of failure, and risk-takers

We all make mistakes. We should learn from them, whether it’s because we didn’t know enough, or because we’re taking a risk. People are afraid of mistakes. We’re afraid of being found out. We need to fight imposter syndrome, and tell the world we are not phonies. So we don’t want to fail, we don’t to make mistakes, so we avoid taking risks.

But what if, when we ask Is it OK to fail? we start asking instead, “is it OK to learn?” or “Is it OK to to take risks?” If you feel like an imposter, that you’re out of your depth, you have 2 options:

  1. Decide you need to learn. I’m currently in charge of a team that’s moving to a more devops culture, and I don’t know enough to know if we’re doing it right. So I’m reading, and testing, and building out my knowledge, so that I can make some mistakes and learn from them, to help me understand the mistakes bigger teams made so I can learn from them too.
  2. Decide you don’t need to learn. Trust your team, or a 3rd party to deal with it for you. Learn how to detect bullshit, and let them deal with the detail.

I loved reading Risk taking and imposter syndrome at Google where Google talk about battling imposter syndrome head-on. When you are surrounded by the brightest and best, you are always going to struggle with confidence. So ask everyone what risks they are taking, and what they’re learning. What do you know today that you didn’t at the last stand-up?

When you are adding value, no-one will think you’re an imposter. And hopefully, neither will you, but when you do, know you’re not alone.

Go learn.

 

 

Categories
code development programming

Your API sucks : standards

Standards are great. They help users understand what to do, they allow developers to write libraries that support multiple packages. Use them when you get the chance.

Not invented here

Sometimes companies can’t help themselves. They need to use something they control, to lock developers in, or because they’re agrophobic, or just to be different. It’s very annoying.

If you really want to ruin a developer’s year, however, take a standard, and almost implement it. Ask anyone using CSS or JavaScript in IE6. Or Netscape Navigator. Ask anyone who uses K&R braces in C# code. Or ask these guys:

At one time I had the pleasure of using WorldPay’s api. It was XML based but instead of just saying ‘it uses XML’ they spent a lot of the documentation describing what they meant by XML, e.g. “an attribute value is enclosed in double quotes”, or “the ‘>’ character must be escaped with >”. This always left me worried that they had written their own parser that might reject valid XML if it didn’t match the subset they described in the documents and if whatever library I happened to be using decided to put an attribute in single quotes or use a CDATA section to avoid escaping content it might go horribly wrong. – Comment from Duncan Booth

Use the platform

Once you have a standard, stick to it. Don’t mix your styles, don’t invent new ways of doing things. Users should only have to deal with one library at a time, not mix-and-match like Frankenstein’s monster.

{
    Name : "Your Woman"
    Address : "<Line1>My House</Line1>
            <Line2>My Street</Line2>
            <Town>White Town</Town>
            <Postcode>EE11EE</Postcode>"
}