The False Learning Trap

I hear this a lot – “I’ll learn it when I’m given a project that I can learn it on”.

Translation – “I’m not going to invest my own time in figuring this out until you tell me I can invest my own time in doing this for you… and pay me for it.”

Perhaps not what you were thinking at the time you said that, but you can’t argue with the logic.

Would that really inspire confidence at an interview or team meeting if uttered as honestly as the above?

Doubtful.

Don’t fall into the False Learning Trap where someone else needs to support and fund your learning initiatives.

It’s not their job – it’s yours.

It’s not their goal – it’s yours.

It’s not to their benefit – it’s to yours.

Instead start saying – “I’m going to figure out some time to learn this so I can start going for the projects that will help me to continue to grow and improve on this skill”.

Now you’re developing the learning base to start making something happen.

Inconsistent User Design

Over the past week, I’ve had two experiences with applications implemented across a variety of platforms with completely different User Experiences – I can hold one up against the other and see the difference.

Different features, different access points, etc, etc.

Even worse, I can look at these experiences across a variety of devices and platforms and see how they are completely different in their implementation as well.

If you are building a solution across a variety of platforms and devices always remember;

  • Consistency is key – don’t limit the user to their device/platform of choice, enable it.
  • Feature parity is Paramount – If you are building all mobile, great, but then we know the back-end services are all the same, so keep it on par from device to device.
  • It’s All On – don’t implement some on, some off functionality because you haven’t finished the feature, hold off on deployment until it can all be on, by making it an inconsistent on/off you are simply inviting negative feedback from users.

Nothing turns a user off more than thinking your application is amazing only to have to stop using it because it doesn’t work here and there when it states it should.

Eliminate those distracting issues so you can get to the core of what users want and start building valuable add-ons for them.

Software Built on Trust

Or Trusted Software is the best kind of software.

It’s built on a foundation of teams and groups working together to accomplish an insurmountable task that no one ever thought could be done.

I have witnessed this happen so many times – and when it does – all I want to do is sit back and watch, because it is amazing.

Requirement Guys, Cloud Girls, Server Boys, Coder Girls, Database Dudes, Super Dudettes – it’s a symphony of development.

Built on trusting one another, trusting the people, trusting the method and trusting the outcome – supporting the failure and celebrating the success.

The best kind of software there is.

 

One Size Does Not Fit All

Have you ever bought a shirt that fit you and given it to someone else who was either smaller or larger than you?

Didn’t fit, did it?

What about following a development pattern that lays out how to build user interfaces on the web while you are building a desktop application?

Probably didn’t fit either, all good ideas, all software, but the fit isn’t there.

What about using a new software methodology?

Agile, Scrum, Waterfall, Lake, River (the last 2 are made-up)…

Did they fit the first time?

Do they apply to your business?

Do they fit within your culture?

There are many ways to solve problems, that is what makes software development such an engaging, enriching and life-committing endeavour where you can learn something new every day and be exposed to a firehose of new ideas on a daily, maybe even hourly basis.

The best part about it – there is not one way or one size that fits all – instead, there are many ways, many sizes that each have their great pieces that we can bring together to make something incredible.

The challenge is knowing and learning which pieces to take.

The Rebuild or the Rebuy

When we rebuild something, we take the problem, deconstruct it to it’s bare bones and fix it with what we have.

When we rebuy something, we identify the problem, build some requirements and hope the purchase of a solution will fix our problem.

Rebuilding involves understanding the problem from beginning to end and investing yourself into design, development and deployment of the solution.

Rebuying involves less effort being spent on development and hopefully more on the actual implementation.

Good developers know that when they rebuild, they are learning, developing and growing.

Great developers know when they need to make the hard call between rebuilding and rebuying something different, something new, something they hope will fix their problem – not being sure – but willing to give it their best shot to get there.