In software development we already have the technical debt metaphor that helps describe the the fact that a quick and dirty approach now, may create problems in the future. For example getting a feature into production sooner but compromising the quality/design/testability/etc. may make future changes harder or more costly: hence paying interest over time for the technical debt that was just created.

The technical debt metaphor is easily relatable to by non-developers and can help facilitate discussions with business owners/stakeholders.

In the real world, paying interest is an acceptable part of life and loans in various forms are not seen as problematic for the majority of people in modern society.

Even though they are an essential part of society however, most people dislike the thought of taxes.

Would the metaphor of a software development tax provide a more visceral reaction and encourage higher quality software where appropriate?

For example, there are “taxes” that come from everyday software development, such as bug fixing or introducing code duplication. Rather than saying “this will add some technical debt to the project…”, we could say “that’s going to increase the amount of tax we have to pay to deliver this…”.

SHARE:

As another (Gregorian) year edges ever closer, it’s a period that offers a natural reflection time on what happened in the past year and the forging, often weakly, of “New Years Resolutions”.

One interesting question to ask for your work (or personal) life is: “what would easy be like?”.

For example, looking back to the past year where was the pain, sadness, frustration, long hours, constant overtime, feelings of falling behind in new technologies, failed deployments, the same bugs re-occurring over and over again, unsupportive management, mean co-workers, feelings of inadequacy, disappointed customers, etc.

you should feel like you’re doing your best work

Take some time. Make a list. Write them all down.

Now imagine what it would feel like if all of the things on the list did not exist in the upcoming year – what would easy be like?

Fixing some of the things may mean radical decisions such as quitting your job and moving employer.

Some things may not be quite as radical: better automated testing to catch bugs earlier.

You probably won’t be able to fix everything on your list. Starting from the point of view that things should be easy, that you should feel like you’re doing your best work, can be a powerful way to frame where you’re currently at and where you want to be by this time next year.

SHARE:

In a previous post (5 Ways to Contribute to Open Source - It’s Not All Code) I mentioned the simplest way to be involved in open source is to simply Tweet about the project or by saying thanks to the creator/contributors. In the post i said “Most open source authors don’t get paid, saying thankyou is not only nice but is good encouragement for the authors to keep the project going”.

I’d like to propose the hashtag #opensourcethanks – it would be great to see the Twitter search for this hashtag fill up with thankyous :)

If you’re benefitting from an open source project, take a minute to send a thankyou Tweet.

SHARE:

I did a little survey to ask what people’s favourite albums were to code to, here’s the results. Hopefully will give some ideas for some different aural code fuel.

I’ve removed spurious entries and also those without albums which included:

SHARE:

There's a lot of negativity sometimes in our profession, just take a look in your Twitter stream.

The tools we use aren't absolutely 100% without imperfection; the vendors of the tools we use don't always go in the direction we want them to; and sometimes the things we invest time in learning go away and it's beyond our control.

We are change

It's amazing to me how many developers seem to hate Windows 8, even to the point of wanting to install start button replacement tools. And that's ok, it’s a personal choice. For me, Windows 8 is the best operating system I've ever used. Another example was the "Visual Studio menus are shouting at me!", for the record I didn't "fix" this "problem" as it didn't bother me. But I know some developers who really hated it.

Perhaps because we are agents of change, we don't like not being in control of change.

I think we're living in a golden age of software development

We have amazing (if imperfect) tools, Visual Studio is great and we have some awesome open source libraries that are super easy to install via NuGet.

Between my Windows Phone and Windows Store apps I've had almost 28,000 downloads. More than downloads though, that's 28,000 people’s lives that I've touched, even if it’s in a small way.

I can have an idea, and within an hour have a prototype running on my touch screen Lumia phone, or my SurfaceRT tablet. This is amazing, really it is, and I take it for granted sometimes.

This doesn't mean we shouldn't highlight problems or disagree with the strategies of our tools vendors. When we do, we can drop f-bombs and call "them" idiots and create more negativity in our profession; or we can call things out with respect and with hope for the future.

It's our community, we get to decide how it feels...

SHARE:

In my many years of being a software developer there’s one thing that I’ve seemed to have experienced on and off throughout this time: Fear.

Fear of:

• Not knowing the latest language/framework/architecture
• Falling “behind” everyone else
• Not being the best
• Not being as good as others
• Being wrong
• Making mistakes
• Looking stupid
• Not being able to learn future technology X

This list could go on…

I’m not alone in these feelings. I have been told the same by, or seen this trait in, other developers I’ve worked with over the years.

We don’t have to be super heroes

So what can we do as a community of developers for us all to feel happier and more fulfilled?

I think if we want to make our professional community better we can start by learning to gives ourselves a break.

Here’s five ways we might be able to do this, feel free to disagree or add your own ideas in the comments section.

1. You Don’t Have To Wear A Cape

We don’t have to be super heroes.

More...

SHARE:

I had a nice comment from @mbartosovsky on Twitter about women in IT and thought I would create a few charts that represent my 12+ years experience in software development.

The results are from me thinking back so the numbers may be slightly inaccurate, however the overall picture is I feel (unfortunately) correct.

SHARE:

Hi Scott,

My name’s Jason, you don’t know me, we’ve never met.

I was inspired by your honesty and openness when talking about your experience with cancer to say the following:

Thanks.

I don’t think that there has been a single week in recent years where I haven’t either read some of your words or heard your voice on one of your many audio endeavours (This Developers Life is hugely inspiring by the way).

There is a lot of meanness on the internets. The way you handle yourself is an antidote to that. It inspires me to try and always be kind, or at the least not to respond to meanness with meanness.

Maybe in our industry we have a greater number of introverts, we work with logic and code, sometimes we forget that we and others are human beings too…

Putting yourself out there is a daunting thing for most of us: there is a huge fear of being wrong or looking foolish. I almost didn’t write this because of a fear of looking too “soft” or “touchy feely” or sounding like an “ass kisser”, but I decided to go beyond that fear and write anyway.

Thanks for the continued inspiration.

Thanks for the knowledge.

Thanks for promoting kindness.

It is my sincere wish that kind words such as these become more common on the Internet, and that the above words contribute in some small way to help you, your family and friends through this difficult time.

Best wishes,

Jason.

SHARE:

So you’ve got a bunch of people together to form a cross-functional team (developers, testers, BAs, etc.), you create you backlog, create a few columns on a wall and throw some cards on it.

Agile complete. Not.

More...

SHARE: