Scott Radcliff

Hits And Misses

Last night Kobe Bryant, arguably one of the best basketball players of all time, set a new NBA record. For misses.

He has missed 13,418 times. Yet, he has 5 championships.

He has 5 championships because he doesn't know how to quit.

This was a great reminder that no matter how many times I fail or screw things up, I need to get up and try again.

Shipping Something

Ouch. Seth Godin nails it. Again.

On taking the plunge and shipping something.

It's easy to be afraid of taking a plunge, because, after all, plunging is dangerous. And the fear is a safe way to do nothing at all.

Source: Taking The Plunge

What Would You Do With The Skills You Have If Not Driven By Money

I posted this to facebook yesterday. Just something that has been floating around my head lately.

There is this question that's been floating around in my head for two days. What would you do with the skills you have if not driven by money, but driven by societal change. In other words, if you could forget about money and only concentrate on touching/changing lives everyday, what would your work look like?

It's especially interesting in my field (software), where we throw millions at useless companies that provide very little value to society. What if we threw just a fraction of that to a company that really puts a dent in something real. Off the top of my head, I can think of hunger, homelessness, retraining the unemployed, domestic violence, human trafficking, and the list goes on and on.

What if you/I only worked on projects that helped improve humanity? The first issue is money. I mean we have to eat I don't have no answer "yet", but I have the beginnings of a thought. If we can throw 55K at potato salad, surely we can crowd fund a developer to work on nothing but software that promotes social good for a year.

To be continued...

Continuous Improvement

It's funny. I think a back to where I was when I was a total newb. There was so much I wasn't good at. It was easy to spot weakness. Pick one weak point and improve. When I thought that was at a good point, pick another one. Repeat. Eventually, through the process of elimination, I got better.

It's easy to lose this skill of noticing weakness and improving. Well, losing isn't the right word. Ignore is more fitting. It's easy to ignore your weaknesses, especially when you work alone.

The minute you join a team, those weaknesses are exposed with a total disregard as to whether you want to address them right now or not. You have to. The choice has been made. Level up.

Noticing Weaknesses and Building on it

At first, it just crushes your ego. It's like being a newb all over again. It's really easy to get down on yourself when you have done what you swore you would never do. You failed to keep up. You fell behind. But not all is lost. It's actually pretty easy to get back on your feet.

Setting Some Measurable Goal Each Week

First, pick one thing your not very good at. Maybe it's code reviews. Maybe it's testing the right things. It could even be as simple as communicating better. Actually, if you suck at communicating, do that first.

Once you have this skill you want to level up, make it your goal for the next week. But it has to be measurable. You have to be able to look at this week and know that it's better than it was last week.

It's really all about shipping

For me, it's all about shipping. If I am shipping more, I am leveling up somewhere. If it's communication that I am working on, and I shipped more software this week than I did last week, I can look and see why. If communication was a big part of that, it will show.

Than I move on to the next thing. Get better every week.

Solving Problems

This is a great piece about what it means to build software. This is exactly where I am at. Programming for programming sake doesn't excite nearly as much as it used to. Solving problems is what gets me up in the morning and excited to build software.

I’m not coding. I’m not building a business. I’m not going to school.

Yep. But I'm not totally on board with not building businesses. I think that's a part of it for me, just not the main part.

I’m here to solve problems.

Solving problems is the main part. The most important.

via Throwing Fireballs

Paul Graham On How To Start A Startup

By far the best talk from How to Start a Startup so far. Entertaining, informative, interesting, and valuable.

Seven Day Startup

7 Day Startup

Dan Norris has written a free e-book on starting a business in 7 days based on his experience. How you feel about the book will probably vary based on your exposure to the startup world and/or bootstrapping businesses. There is nothing about VC or pitches. Just a game plan for worrying only about stuff that matters and how Dan approaches his business.

I had heard most of this stuff before. But I did enjoy the book and it has changed my thoughts on an upcoming project.

Hey! It's free. Go read it.

Take Your Time

This is a great reminder to slow down and think. Do your best work.

Definitely something I struggle with.

Writing Good Software Takes Time

Code Is Art

Programmers need to claim the extraordinary nature of what they do.

Is Computer Coding Art?

Creators And Guilt

Allan Branch from Less Accounting describes my feelings about guilt when programming.

Allan uses entrepreneurship as a basis for an example of feeling guilty about not getting enough work done, or working too much, or not actually finishing anything. I feel all of these as a member of a dev team. Not necessarily an entrepreneur role, but all the same symptoms.

Here's how it feels for me.

Feeling Guilty for not Working Enough

I thought it was just me, but I guess not. I will often look at my work at the end of the day and have this feeling of not pulling my weight. Feeling exhausted from working my tail off all day, just to see that it doesn't look like I got much done.

Now that I am on a team, I have this feeling of making sure I don't let the rest of the team down. It's true that I definitely have more days where I feel bad about what I've done rather than proud of the amount of work I've contributed. I don't know what the fix is. I've tried a few things. Instead of just tracking what I believe are billable hours, I have tried tracking everything. Not for the "boss", but to help me see that even when I am not producing billable hours, I am still contributing something to the team. Honestly, it doesn't help much. When it's the end of the week and it's time to submit hours and they are lower than I think they should be, that guilt is still there.

Feeling Guilty for Working Too Much

There is a flip side. Working so hard to get to a point where you feel you are contributing enough that you actually work too much. This feels equally as bad. As Allan mentions in the article, when you put in extra hours to compensate, you have to take them from somewhere. For me it's my family. The words "Dad, you work too much" are spoken more than I would like to admit at my house.

Making Assumptions

I think a large part of this are assumptions. Most of us have other people we work with. And most creative people set very high standards for themselves. It's easy to think that the other person is not happy with what you are producing, when in fact you really don't know what they think. I'm super guilty of this. I often assume that I know what the other team members must be thinking. This is dangerous.

I'm going to list a few things that I think might help with guilt

1) Never assume you know what the other team members are thinking. Always ask if you really want to know. Beware. You may not like what you hear.

2) Keep an open mind about what contributing actually is. If you're a developer, it doesn't always have to be lines of code. If you're a designer, it doesn't always have to be sketches or comps. You bring way more to the table than what your hands can do.

3) It's okay to give an honest day's work. And sometimes a honest day's work falls short of your expectations. That's okay too. Nobody died and you can try again tomorrow.