Tag Archives: psychology

Stop Taking Yourself So Seriously

There is a pretty good chance I screwed up today.

There is a pretty good chance that this blog article will flop.

Maybe, you’ll come here to my blog, expecting to be enlightened, but instead find a bunch of worthless drivel that wasn’t worth the time it took you to read.

But, guess what? I don’t care.

It’s not that I don’t care whether or not I am producing good work–I am trying my best.

It’s not that I don’t care whether or not the content I am creating is valuable–I sincerely hope it is.

It’s not even that I don’t care, because it’s not a big deal–my blog is one of the main ways I make money, so it is sort of a big deal.

I don’t care, because I have learned to not take myself so seriously. I have learned that what I am doing is just not so important, and that every little failure or success does not determine the fate of the world.

Sure, I’d like to have success, but failure–although not preferable–is OK as well.

It’s time to chill out

Seriously. It is.

seriously Stop Taking Yourself So Seriously

If you are reading this blog post, you are probably a software developer. Now, it might be that you are working on a very important piece of a software system that will save lives or completely change the world but chances are, you are not.

Even if you are, your part in that software is probably relatively small and not all that important.

I’m not saying this to belittle you. I know that most of us like to think about how important we are. Instead, I’m saying this in the hope that you’ll realize that in the grand scheme of things, most of what we do doesn’t really matter.

Why is this so important to me?

Why do I even care about delivering this message?

Because, a large number of atrocities and dumb mistakes are committed by people who have the tendency to take themselves too seriously.

But, what does it mean to take yourself too seriously?

It means that you care so much about your own opinions and the image that you are portraying that you force a sense of importance on too much of yourself and on other people as well.

So what if someone is wrong about test driven development.

So what if people are using IoC containers incorrectly.

So what if you just messed up and said something embarrassingly wrong.

So what if you did something that makes you look like an idiot.

I mean, is it really that important? Is whatever you are caught up in and upset about really worth stressing about? Is it really worth hurting someone else’s feelings and causing a ruckus?

(If you still think so, do everyone around you a favor and read this book please.)

Most of the time it isn’t, but we tend to think it is–myself included, I can’t escape judgement. I take myself too seriously from time-to-time.

Most of the time, though, I find that whatever has me so upset, whatever has me feeling agitated or frustrated with the world, really isn’t that nearly as important as I imagined it to be.

You only have so much mental and emotional energy in a day

batteries Stop Taking Yourself So Seriously

Why waste it on being upset about things that don’t matter.

I’m just about to shut off Facebook permanently, because it is disturbing to see so many people arguing about ridiculous news articles and political agendas that don’t really matter.

Sure, it is important whether or not guns are banned or not in America, but most of the people complaining one direction or the other are not going to do anything about it. They are just wasting useful emotional and mental energy arguing on Facebook and they are mentally and emotionally draining other people as well–not to mention losing friends and burning bridges.

I see it all the time in workplaces as well. I’ve been guilty of it plenty of times; fighting for the 98% effective solution when the 96% effective one will do.

It is easy to get sucked into the trap. It’s easy to start to think that our opinions are just so gosh darn important. It is easy to start to believe that what we are doing and how people perceive us is a matter of national security.

But, the truth is, it is exhausting to do so.

When you wake up in the morning, you’ve only got so much patience. You only have so much focus. You can choose to spend that energy fretting over little things that aren’t really important, or you can put it to work actually achieving something–making someone’s day better rather than tearing them down. It is up to you.

It might sound like I’m upset about this topic

But I’m not. I’m just writing a blog post and this is what came to mind.

Sure, I’d like you to agree with what I am saying. Sure, I think I’m right, but perhaps I’m not. Perhaps the name of that variable really is that important. Perhaps it is worth getting in a shouting match over whether or not we should deploy troops in Iraq.

The point is, it doesn’t matter.

I’ve decided to stop taking myself so seriously.

I’ve decided to stop caring so much about what other people think.

I’ve decided to stop wasting so much of my time in petty squabbles.

I’ve decided to stop wasting so much of my energy on things that don’t really matter.

I’ve decided to instead just do the best I can, realize that other people are probably doing the same–as optimistic as that view may be–and live and let live.

Life is too short to take yourself so seriously.

I’m a software developer on a quest to make the complex simple. I help other developers live better lives and become the best version of themselves possible through my blog posts, courses, videos, podcasts and emails.

Join me on my quest here.

 

What to Do When You Don’t Feel Like Writing and You Have Nothing to Say

I spend a lot of time doing two things: blogging and telling other developers the benefits of doing things like starting their own blog. (Occasionally I squeeze in a little bit of time to code as well. And my wife says I spend too much time answering emails and checking my phone—she wanted me to add that to this post.)

So, I can tell you that one of the major pains I am well acquainted with is that of writing when you don’t feel like writing or you just don’t have anything to say.

I experience this frustration myself—heck I am experiencing it right now. I decided to write this blog post because I couldn’t come up with anything else to write about. And, to top it off, I don’t feel like writing either.

tired thumb What to Do When You Dont Feel Like Writing and You Have Nothing to Say

But, let me jump ahead and give you a little secret: by the time I’m halfway through this post, not only will I know what to write about, but I will feel like writing.

I know this from experience, and it is part of what keeps me going on days like these.

Writing is difficult

Writing isn’t an easy thing to do.

It is hard to spill your brains onto a blank piece of paper and not make it look like spaghetti.

It’s difficult to constantly come up with new ideas, week after week.

But, by far, the hardest part of writing is just sitting down in front of the keyboard and typing. Even now, as I am typing these very words, a million other things are vying for my attention, calling me away from the task at hand.

Most software developers who start a blog, end up abandoning that blog, because they never learned how to grit their teeth, glue their ass to a seat and write.

Sure, it starts out fun. When you first throw up your blog on the internet, you are full of ideas. You could write a blog post each and every day—not because you are more creative when you first start, but because you are more motivated. The whole process is still very new and enjoyable.

But, fast forward a couple of months—or a couple of weeks for those of us with ADHD—and that shiny-newness of blogging wears off. That little fairy that was sitting on you shoulder telling you what to write is gone—it’s just you and the keyboard.

This is exactly when you have to search deep down inside of yourself and find the grit beneath your soft cushy exterior. You have to decide—that’s right, make a decision—that every week you are going to write a blog post and nothing is going to stop you from doing it.

You’ll want to start over and give up

Even as I write this very sentence, I want to go back to the beginning of my post and delete everything. It’s no good. My thoughts are scattered; my analogies are crap; no one cares about what I have to say on this subject.paper thumb What to Do When You Dont Feel Like Writing and You Have Nothing to Say

I’ve been writing blog posts just about every single week for over 4 years, and I am still smacked in the face with the stick of doubt just about every time I sit down to write. So, I can tell you from experience, that part doesn’t get any easier.

But, you can’t let that stop you. Your face might be swollen, some of your teeth might be missing, you might have to squint to see out of one of your eyes, but as soon as you care that what you are writing is no good, you’ll stop writing—permanently. You’ll fall right off the wagon.

By the time you’ve gotten this far into my own essay, it doesn’t matter if it is good. I’ve got your attention already. I can’t embarrass myself any further, because if you didn’t at least sort-of like what I have said so far, you wouldn’t be reading this sentence to begin with.

I’ve come to the realization that you can’t always hit homeruns. Sometimes, you write crap. Sometimes, what you think is your best blog post turns out to be so terrible that no one makes it past the first paragraph.

But, sometimes what you think is terrible, turns out to be the most popular thing you’ve ever written.

The point is, you can’t know until you hit that publish button and even if you could, it doesn’t matter, because you can’t write for other people, you’ve got to write for you.

Not because you are writing something that you’ll someday read later and say “oh, yes, that is how I solved that problem in the past”—although, that does happen from time to time. Instead, you have to write because you made a commitment to yourself and the commitment wasn’t to string marvelous words into sentence on paper, but instead just to write—it doesn’t have to be any good.

The secret is to keep going

I’m sure you’ve noticed by now that I haven’t really told you what to do when you don’t feel like writing and you have nothing to say, so, here it is: write.

Yep, that’s it. It’s that simple.

Take some duct tape, put it over your mouth, shut up, stop whining, pull up a chair, sit down at the keyboard and start moving your fingers.

You can’t sit there and type and have nothing to say. Now, what you have to say, you might think isn’t any good—and it may be utter crap—but there is no reason that has to stop you from writing. Just do it.

There are a million ideas bouncing in your head, but some of those ideas will only come to the surface when you have decided you are going to sit down and do the work.

Don’t believe me?

Try this exercise on. Right now I want you to close your eyes, and think about nothing. That’s right, think about absolutely nothing—I’ll wait.

How’d that go for you? Were you able to think about nothing?

So, don’t tell me you don’t have something to write about. Of course you do. Your problem—and my problem—isn’t writing, it’s typing it out.

P.S. – By the time this post goes live, I’ll be in the middle of launching my How To Market Yourself as a Software Developer program. If you liked this post, go check out the program. It has a whole video course on creating your own developer blog and making it successful.

The Dark Side Of Software Development That No One Talks About

Hey, you.

Yeah, you.  Psst.  Come over here.

I’m going to tell you something that you may not have heard before.

Are you ready for it?

Software developers are jerks.

Don’t get me wrong, there are lots of great developers and nice people who are software developers, and there are lots of great supportive environments and thriving communities in software development land, but there are also lots of jerks.

You have to learn to grow a thick skin

You don’t hear this much, because it isn’t really nice to say.  And hey, I’m an eternal optimist, so I’d rather not look at the negative, but ignoring reality doesn’t make it go away.

thick skinned thumb The Dark Side Of Software Development That No One Talks About

The truth is not everyone has your best interests at heart.  The truth is that a large number of people would like nothing more than to see you fail; to prove once and for all that they are smarter than you.

Chances are if you are doing something unique or you propose a new idea, you’ll have more critics than supporters.  I don’t say this to be mean or to discourage you—I actually have the opposite intent.  Rather, I say it so that you can be prepared and not think it has anything to do with your personally.  Hopefully, I can help you grow the kind of thick skin you are going to need if you are going to succeed as a software developer.

There has been a good amount of griping and general banter about women in tech lately.  Both sides of this imaginary war have crossed lines and drawn blood.  I’ve stayed out of it so far, and I’ll continue to—I’m not taking sides.  But, in some ways this whole debate has shown just how nasty people can be in our industry, and over some pretty petty things.

The problem is that most software developers, male or female, aren’t really ready for the nastiness they are about to encounter when they start writing code as a career.  Worse yet, much of this nastiness is disguised in a very passive aggressive manner, so targets of this ire aren’t even aware of it—at first.

Lots of us could definitely stand to read a book like “The Hard Truth About Soft Skills,” or one of my favorites that I recommend every chance I get, “How to Win Friends and Influence People.”

Where does this vileness come from?

We work in a sort of strange field where intelligence and ability are highly prized, but some of these same qualities made some of us victims of aggression and abuse earlier in life.

This tends to result in a culture in which many of the participants are constantly trying to prove themselves and evaluating themselves against others.

To put to plainly, it means there are lots of sensitive and bloated egos floating around.

It is sort of a “kick the dog” syndrome where software developers who were kicked earlier in life, or even earlier in their careers, tend to feel justified in kicking the programmers who they see beneath them.

This same kind of mentality also tends to foster cynical thinking and an outright rejection of any idea that doesn’t self-originate.

But, I probably don’t have to tell you this, so much as to remind you of it, because if you’ve been in the industry for any amount of time, you’ve probably felt and experienced this yourself.  You may even be a perpetrator of it—we all are from time to time—just some of us more than others.

What you can do about it

So you might be wondering what my purpose is in telling you all this.  Am I just complaining for the sake of complaining?

No, definitely not.  Like I said, I spend much of my day trying to see the positive.  I don’t like to dwell on the negative.

My real purpose is to put this out in the open so that I’ll stop getting emails from tired, beat up developers or want-to-be developers who have been beaten down so hard by their peers that they feel that they are somehow below them.

Everyone feels doubt in their abilities and worth from time to time, but you’ve got to learn to recognize where the doubt and fear is coming from.  Sometimes, it is a healthy dose of skepticism in our own abilities that keeps us from floating our head way up above the clouds, but many times it is just the reflection of others who are making us feel inferior.

I’ve sat through countless meetings where good, smart software developers who had good opinions and ideas kept their mouth shut and didn’t say a word.  I’ve been to leadership and effective communication classes that told me that the vocal participants in the room were to blame; that they were being too assertive and aggressive and forcing others into the room to become more introverted.

But, you know what?  That is hogwash!

stand up thumb The Dark Side Of Software Development That No One Talks About

Are you going to live your life waiting for someone else to step out of the way, so your quiet voice can be heard?  Or are you going to make your own voice louder?

You are much better off realizing that people are jerks and learning how to speak out and deal with criticism than you are believing that you are inferior and not worthy of a seat at the table.

Don’t blame your own situation on other people being egotistical loud mouth jerks and accept their bullying and allow them to project the image of how they want to see you onto yourself.  Instead, realize that is just the way it is and you have to learn to adapt to this environment.

As much as I’d like it to change, it probably won’t, so at some point you’ve got to start living in reality or find a more peaceful and accepting atmosphere.

Don’t be part of the problem

Just because the situation is somewhat bleak, doesn’t mean you have to be part of the problem as well.

I originally started this blog, because I was fed up with all the egos that were trying to make programming seem so much harder than it really is.  My whole mission in life for the past few years has been to take things that other people are trying to make seem complex (so that they can appear smarter or superior) and instead make them simple.

I charge you with taking up the same quest.  You don’t have to start a blog dedicated to the cause or wear a Simple Programmer T-Shirt, but you can start helping other software developers and making them feel like they can do it instead of making them feel like they need years of practice to attain your level of skill.

If we want to make a difference in the community, we have to start trying to make things seem simpler rather than harder.

There are plenty of people out there who will gladly challenge a new idea or tell you why you can’t accomplish some goal, but there needs to be more of us—especially those of us who’ve been in the field for awhile—who tell people why they can do it and how easy it really is.

Real strategy to deal with this problem

Dealing with jerks and negativity is hard.  It is really hard.

In my career, I’ve dealt with my fair share of it, and I still deal with it today.  In this post, I just highlighted the problem and offered simple suggestions, but I’m actually working on a much bigger project to distill some of these specific software developer career tips into a bigger package.

If you are interested in finding out the moment this product is officially launched, sign up here, and I’ll be sure to let you know.

How about you?

Do you run into lots of egos in software development?  How do you stay positive and not let them crush your spirit?

How To Deal With Making Mistakes

What do you do when you make a mistake?

Not just in your job, but in life in general?

I’ve made some pretty big mistakes in my career

.mistake thumb How To Deal With Making Mistakes

Just last month I was giving a talk at the Orlando Code Camp and I forgot to bring an adapter to go from DVI to VGA for my MacBook.

That was a huge mistake!  I spent most of the presentation trying to get someone else’s laptop to work with my setup.  Finally, in the last 5 minutes I managed to actually get my demo started.  (Luckily the talk was about how to create a web service using Service Stack in 5 minutes.)

I’ve made huge career mistakes, like quitting a job with a certain company that got sold a year or two later, which would have resulted in a pretty big payday for me.

I’ve made dumb coding mistakes that have caused bugs to go into production and resulted in some embarrassing moments for myself.

I could take up this whole post just listing all the mistakes I have made.

The point is…

Everybody makes mistakes

It doesn’t matter who you are or how good you are at development or whatever else you are doing, you’ve made mistakes in the past and at some point in the future you’ll make them again.

The fact of the matter is that mistakes are just part of life.

We can try to avoid them.  We can try to deny them.  But, regardless of what we do, mistakes will happen, so it’s best to learn how to deal with them.

Own up to it

The most important thing to do when making a mistake is to own up to that mistake.

Chances are everyone else already knows that you made the mistake, and no amount of excuses or finger pointing will change anyone’s opinion of it.  Trying to avoid the ownership of a mistake is more likely to make you look even worse and damage your credibility.

Sometimes the mistakes truly are only visible to you.  In those cases it can be even more difficult to own up to the mistakes.

I have a tendency to try and pretend like somehow the mistake I made was not a mistake at all, but rather the wisest choice I could make given the set of circumstances I faced, regardless of how bad the outcome was.

This is called justification.  Not only is it not healthy, but it is a complete waste of time and energy.  When you justify your mistakes instead of acknowledging them, you completely void any possible benefit you may have gotten from making that mistake.

Justifying mistakes is tantamount to throwing your hands up in the air and saying “what comes, comes.”  It is taking away your power and control over your life and career and giving it to everyone else.  It is becoming a victim of your circumstances instead of a master of your destiny.

Long story short, when this !@#$ hits the fan in your life, it’s probably your fault, so own up to it.

Fix it (if possible)

You can’t always fix your mistakes.

Once I deleted my backup folder and emptied the recycle bin, BEFORE I had copied that folder to my new backup drive.

That was it, it was done.  There was no fixing it at that point.  Oops.

Fortunately though, in many cases mistakes are fixable if they can be identified and you are willing to own up to them.

There is a wise old Turkish saying that goes something like this:

“No matter how far you’ve gone down the wrong road, turn back.”

I always try to remember this saying, because the first tendency I seem to have when caught in a mistake is to try and ride it out with the foolish thought that I’ll save what I invested so far by continuing to go down the wrong road.  As if somehow the wrong road will magically become the right road.

If you have made a mistake and you know what that mistake is and that mistake is fixable—fix it!

Don’t try and “ride it out” or build on top of it.  Tear down the building to the foundation and fix the mistake, before it can get any worse.

Little mistakes become big mistakes when we let them fester.  Big mistakes become tragically life altering mistakes when we ignore them.

Guard against future mistakes of the same kind

Now, like I said before, we can’t always fix all of our mistakes, (although you’d be surprised how many mistakes you can actually fix if you are willing to eat a little humble pie,) but we can guard against future mistakes.

The first thing that I try to do after I have made a mistake that I have identified, owned up to and have tried to fix, is to figure out why the mistake happened and how I can prevent it from happening again.

Far too many people make the same mistakes over and over again, because they don’t take careful steps to prevent the mistake from happening again.

prevent thumb How To Deal With Making Mistakes

It is very easy to move on from a mistake or dwell on the mistake without making any effort to analyze why the mistake happened in the first place and how it could be prevented in the future.

Many times in a rush to move on to the next thing, I’ve been guilty of this meta-mistake myself.

It is very important to examine a mistake with a clear head and honestly evaluate what brought about the mistake and why exactly it was a mistake.

Once you know what caused the mistake, it is important to put in place a procedure or some other sort of guard that will ensure that mistake doesn’t happen again.

In code, I’ll often add a new unit test or some other type of automated test to ensure that a bug I fixed can never happen again.

In life, I often don’t find it that easy.  Many times the mistakes and the consequences of those mistakes are quite far apart, so it can require a very careful and honest analysis to determine the connection and find a future remedy.

I have a high tolerance for people making mistakes, because I know we all make mistakes.  But, my tolerance wanes for people who continually make the same mistakes again and again.

Single mistakes are expected and accepted, repeated mistakes indicate incompetence and carelessness.

Move on… quickly

It is to easy to get hung up on a mistake and become paralyzed by it in such a way that it prevents you from having future success.

I seem to have an instinctual desire to throw away what I am doing or try to completely wipe the board clean, whenever I make a mistake.

I remember as a child playing Nintendo and hitting the reset button over and over again every time I died on a level or messed up in the slightest, instead of continuing on and doing my best from that point forward.

I’ve embarked on projects and ventures where I have made mistakes and instead of plowing forward to learn from them, have simply given up.

Giving up isn’t the same as moving on.

Sometimes it’s the same and you need to know when changing directions is the right course of action, but often we are so caught up in our mistakes that the continual focus on those mistakes shifts focus from what we should be working on and derails us completely from our track.

I’ve learned that is it important to quickly acknowledge the mistake, take corrective action, guard against it in the future and then move on.

This means letting go of it and accepting mistakes as the only way to move forward.

Fail, but when you do, just be sure you are leaning in the direction of success. Then when you fall it will be forward.

I’ve had many situations in my career where I know I’ve screwed up and I know what I did wrong, but the process and consequences of my mistake have drained the enthusiasm and spirit out of me to press on.

In those situations I’ve had to tell myself that I was not going to give up and I was going to make the best of my current situation, regardless of what it is, instead of making the worst of it.

What about you?  What kinds of mistakes have you made and how did you recover from them?

7 Reasons Why You Should Tackle Hard Problems Last

I always hear the advice that we should tackle hard problems first.

It seems like pretty legitimate advice, and many of the reasons for saying so make sense, at least at a surface level.

The reasoning usually revolves around the idea that by tackling the hard problems first you can eliminate your biggest risk early and everything will be smooth sailing from there.

When you really think about the reasoning for solving hard problems first though, most of it is not actually reasoning, but based of off one emotion… fear.

We tend to think it is best to solve hard problems first, because we are thinking about eliminating our fear, not because we are thinking about what approach has the highest chance of success or is the most optimal.

I call this FDD, or Fear Driven Development.

And when I think about it that way, I find myself hard pressed to find a real good reason for tackling hard problems first besides being able to abort early.  Which, in some cases might be good, but I’d rather focus on success.

tackle thumb 7 Reasons Why You Should Tackle Hard Problems Last

Here are 7 reasons why it might be a good idea to tackle the hard problems last instead of first.

1. Solving easy problems first gives you momentum

When a large ball starts rolling down a hill, it picks up speed rapidly and that large ball can bust through many barriers that it couldn’t before, simply because of one thing it has after rolling down a hill that it didn’t have before—momentum.

On the converse, trying to push a heavy ball up a hill is pretty hard.  And if there are barriers on the way to the top of the hill, not only do you have to fight gravity, but you have to be able to push extra hard to get through those barriers.

momentum thumb 7 Reasons Why You Should Tackle Hard Problems Last

Life is hard enough, why make it harder?

I recently received an email from a developer that was concerned that his team wasn’t gelling and that they didn’t have the expertise in the technology needed to solve the complicated problem ahead of them.

They were going to start the project by trying to integrate this fairly complex technology and he was afraid that it would cause them a large delay before they would be able to get version 1 out.

My advice?

Start with your simple problems; get working software out there as soon as possible.  Not only will the team gel much more easily as they are having success and making real progress, but that momentum will help them when it is time to solve the more difficult problem. 

Even if they have to throw the first version away, when they get to the hard problem, the momentum alone will make them much more likely to reach success in the end.

I could give 100 examples of how solving easy problems to gain momentum can benefit you, but you probably already know intrinsically that this is true.

Long story short, get a running start before taking a big leap.

2. Avoid solving the wrong problem

wrong thumb 7 Reasons Why You Should Tackle Hard Problems LastThere are few things worse than spending weeks or months solving a difficult problem, only to find out in the end that you actually solved the wrong problem.

The big problem with solving the hard problems first is that the hard problems usually require a large amount of context in order to fully understand them.

It is very hard to get the right context for a hard problem when we take it out of its natural order of progression and artificially cut it to the front of the line.

You’d probably like to start a college class by taking the final exam first, so you don’t have to worry about it, but the problem with doing so is that you’ll lack the context and information to understand the questions and to know the answers.

When we try to tackle problems out of order to avoid leaving the hard problems to the end, we end up losing all of the learning and context that would help us to solve the hard problems at the end and we are much much more likely to end up solving the wrong problem, which is a complete waste of time.

3. Someone else may solve the problem for you

Sometimes procrastination is a good thing.

Sometimes, when you purposely push off solving a hard problem till the end, you end up finding that someone else already solved your problem.

editing thumb 7 Reasons Why You Should Tackle Hard Problems LastI was working on a Pluralsight video last week, using Camtasia 8 for editing, and I found that one of the video segments I was tried to load up was crashing the application every time.

I spent a few minutes trying to troubleshoot it, but nothing I was trying was working, so I had to make a decision.

I had 3 choices:

  1. Keep trying to solve this hard problem before moving on.
  2. Go on and do other videos and send off a support request to see if they could handle it.
  3. Make a new project and re-edit all the clips.

Choices 1 and 3 involved tackling a hard problem right then and there.

Choice 2 was to tackle easy problems and see if support could solve my hard problem for me, and if not, I would solve it at the end.

I ended up choosing option 2 and it paid off.  It turned out Camtasia support was able to solve my problem.  By the time I needed the project to complete my course, they had solved my hard problem for me and I didn’t waste any time upfront trying to tackle it myself.

Now it could have worked out differently; I might have had to solve the problem myself at the end, but instead of assuming I would have to and wasting perhaps a day or 2, trying to solve the problem myself, I pushed it off and kept working on easy problems and I gave someone else a chance to solve my hard problem for me.

It doesn’t happen all the time, but many times if we push off the hard problems we face, we find that by the time we get to them, someone else has already solved the problem for us.

4. Your own subconscious mind may solve the problem

When I said someone else might solve the problem for you, that someone else might actually by you—at least your subconscious mind.

Have you ever had the experience of thinking about a problem and not being able to figure it out, but then you wake up the next morning and suddenly have the answer?

It seems that our subconscious mind is more powerful than we are aware of.

sleeping thumb 7 Reasons Why You Should Tackle Hard Problems Last

In many cases, if we know of the hard problem we need to solve and have thought about it a little bit, our subconscious mind will start working on the solution, even though we are not aware.

Obviously this isn’t going to work all the time, and your subconscious mind isn’t going to write a bunch of code for you, but in many cases there is at least some benefit to throwing the problem off to our internal “worker thread.”

5. You are more committed to solving the hard problem when you risk everything you do so far

One benefit to saving the hard problem for last is that you have some extra motivation in the form of loss aversion.

It has been demonstrated in several experiments that people tend to try to avoid losses versus acquiring gains.

We can use this knowledge to our advantage by doing the easy work first and letting our loss aversion help motivate us to solve the harder problems, because we don’t want to lose all the work we put into a project so far.

By starting with easy problem, we put some “skin in the game.”

If we try to solve the hard problems first, we have nothing to lose, so we are much more likely to give up.

6. Hard problems are often easy problems bundled together

bundle thumb 7 Reasons Why You Should Tackle Hard Problems LastI’ve talked many times about breaking things down and trying to keep things as simple as possible.

And it turns out that many hard problems (not all) are decomposable into many small easy problems.

If you strive to never solve hard problems and to always push them off, you may actually find out that you never have to solve hard problems.

Many times we can chip away at hard problems, by taking bits of them off a little at a time and solving those easier problems.  Eventually, you may find that you’ve reached the tootsie roll center of your hard problem lollipop and it is filled with chocolate candy!

Now, some problems aren’t very easily decomposable, but a good majority of problems are.  Once you develop the skills to chip off bits of hard problems into smaller easy problems, the world looks like a much more conquerable place.

So, saving hard problems for last and breaking off little pieces of them as you go, can be a good strategy to help you to wear down your opponent before you have to face him.

7. Some hard problems are never truly solved

One of the big problems with tackling the hard problems first is that they tend to fill up as much time as you’ll give them.

If I give you an easy problem, like write a function to reverse a string, there isn’t much to think about.  You can solve it a number of different ways and there isn’t a huge difference in the efficiency of the different methods of solving it.  It is pretty unlikely you’ll spend weeks revamping your solution and thinking that it’s not quite right.

But, if I give you a problem like, create an in-memory database, not only is it a hard problem, but it has a huge number of possible solutions and can be optimized from now until the end of time.  You could spend 2 weeks working on that task or 2 years.

The problem is that many hard problems don’t have a good scope to them when they are solved in isolation.

If you design an engine for a car that isn’t built yet, you won’t know when you are done.

But if you design an engine for a car and you know how much it weighs and know what kind of transmission it will use and what kind of fuel efficiency it needs to have, you can have a much clearer understanding of when your engine design is done.

If you save the hard problems for last, the scope of those hard problems will be much more defined, which will keep you from wasting valuable time over solving a problem or, like I mentioned earlier, solving the wrong problem altogether.

If you like this post don’t forget to Follow @jsonmez or subscribe to my RSS feed.

1 Million Dollars to Succeed

Let me ask you a question.

How would you develop your next software project if I told you that if you “succeeded” you would be given $1 million dollars, but if you failed you would get nothing?

money thumb 1 Million Dollars to Succeed

Success of course is a very fuzzy term, but let’s assume that success means:

  1. You built a working functional product
  2. Your customers are happy with it, content enough to call it done
  3. You delivered it on time
  4. You delivered it within budget
  5. It can be fairly easily modified and maintained with its current design for the next 5 years.

This is an all or nothing proposition.  Everything is on the line.  If you were to succeed, you would be rewarded handsomely, but if you fail, your effort would be entirely wasted.

Oh, also, you can’t work more than 8 hours a day 5 days a week—no winning by heroics alone.

Why ask this question?

Simple, because after thinking about “how to build software” for the last 10 or so years, (in my beginning years, I didn’t really ponder this question) I have decided the answer to this question is the way that software should be built.

I don’t mean that developers should be given an all or nothing proposition.  What I mean is that we should be building and designing software as if I proposed the above situation.

This might sound a bit crazy, but think about it for a bit.

Most developers today are paid a salary.  Some salaries have bonuses attached for performance, but rarely are we put in a situation where making mistakes or not being as efficient as possible results in dire consequences.  The worst that can happen in most cases is that we would get paid for the work we did and then be looking for a new job at the end of the project.

Losing all the time we put into the project and losing out on an opportunity to make a million dollars would be some consequence.

We’d think about software development quite differently

think thumb 1 Million Dollars to Succeed

It’s really hard for me to answer the question of whether or not practices like TDD are worth it.  I mean sure, I tell my manager it is.  I emphasize quality over speed.  I say we need to do this or that, but honestly I don’t really know.

I’ve never been put to the test.

No one has ever said to me, “succeed or die.”

No one has ever put the consequences of my choices directly in my own hands.

Never have I actually had to weigh the weight of extra time spent refactoring code, writing unit tests or using an ORM instead of writing SQL directly in my source code.

I choose technologies because they seem good to me or it seems like they’ll help me get things done faster, but I am never really staking much on that choice.

Sure, I may be staking my reputation, or I might lose my job, but chances are I’ll just blame some failure on some other reason or worse yet, I won’t even recognize my failure, because it will be disguised by “good enough.”

“Man, John, you are a big fraudulent a-hole!  I can’t believe you go around touting to know stuff, leading people down paths that you yourself don’t even know are correct.  Burning up other people’s money in your test lab of software development.”

Maybe it’s true.  Maybe I am a big ignorant and arrogant jerk, but somehow I feel that I am not alone.

I’m not saying we don’t or shouldn’t have strong convictions.

I’m not saying that we don’t have good reason to believe the development methodologies and practices we suggest and follow are correct.

What I am saying is…

Our beliefs about software development are mostly theoretical

theory thumb 1 Million Dollars to Succeed

8 years ago I would have told you that you needed to create UML diagrams before you write any code.

5 years ago I would have probably emphasized the importance of always having an XML schema.  I would have told you data without schema is meaningless.

I don’t hold either of those views today.

Perhaps you’ve changed your views in the past few years as well?

The point is that even though we may be down in the trenches doing software development and to some degree finding out what works and what doesn’t, we are basing the results on OUR motivations not the motivations of our customers or our employers.

So, we may eventually get good at making things easier for ourselves, but unless your feet are held to the fire, you’ll never really optimize for building the best software as efficiently as possible.

If you think you already are focusing on building the best software as efficiently as possible and I am just full of crap and you don’t operate that way, I would strongly suggest doing a thorough self-check and also please tell me the secret of the most efficient way to build software, because I definitely want to know.

What about startups or open source projects?

You might be tempted to think that working for yourself or not for money at all would change things, but I’m really not sure that is the case.

I’ve worked on plenty of my own software projects where my fate was directly in my hands.

I’ve built applications like PaceMaker where my financial success with the endeavor was directly tied my own efforts and my efforts alone.

But, do I think I built PaceMaker as efficiently as possible?

No, definitely not!

The problem with PaceMaker and other projects where there is a big potential upside, is that the upside potential is not guaranteed.

I can assure you that if someone said to me that I have 6 months to build PaceMaker and if I succeeded (according to the rules I stated above) that I would be given $1 million dollars, but if I failed I would be given nothing, I would have probably gone about the whole process an entirely different way.

I’m not saying I would have built it with perfect efficiency, but my motivations would have entirely matched up with the footprint of building software as perfectly as possible.

What I mean by this is that I would be trying as hard as I could to do what I absolutely believed was mostly likely to benefit me, and by doing so I would be trying as hard as possible to completely optimize the process of building that software.

What can we do about this?

Now I can’t tell you how I would have built PaceMaker had I been given the million dollar challenge.

There is no way that I could objectively put myself into that situation and give you an answer.

Would I have bothered with unit tests?  Would I have have created backlogs and written UATs to make sure they pass?  Would I have used an IoC container?

The plain and honest answer is, I don’t know.  All I know is that I would have done things differently and on any software project you’ve worked on, you probably would also.

There are a few things we can gather from thinking about this hypothetical proposition.

  • Don’t think you know the answer, but at the same time have convictions about what you currently believe.  Just hold on to those convictions loosely.
  • Even though you can’t realistically be completely objective and build software as if someone was going to pay you 1 million dollars (just like you can’t tickle yourself) you can still try to think as much as possible with this mindset.  It is a worthwhile exercise to imagine as if the decisions you are making and the convictions you are holding onto are based on idealism or reality.  We could also all examine and at least understand our own motivations.
  • Recognize others are in the exact same boat you are.  Don’t believe everything an expert says or even believe there are experts.  Experience and wisdom count for something, but no one has anywhere close to all the answers.

I’d love to see this experiment actually played out.  I’d really be curious to see what the outcome was, especially in a team situation.

Perhaps someday, someone will actually conduct this experiment and share the results.

What about you?  How do you think being given the million dollar challenge would change the way you develop software?

The Myth of the Super Programmer

I received an email this past week that disturbed me.

Basically the author of the email inferred that most of the topics I talk about in my blog posts and Pluralsight videos are relatively easy topics, but that I had hypocritically suggested that interviews should be hard and should be designed for “real programmers” or super programmers.

Essentially the point of the email was that application developers are not “real programmers” and “real programmers” do hard stuff with difficult math.

Searching for the super programmer

super duper awesome programmer thumb The Myth of the Super Programmer

I don’t think this attitude or understanding about programming and software development is unique or irregular.  Even Scott Hanselman has called himself and thought of himself as a phony.

His post on the subject resonated with me, because I think the same thing about myself sometimes.

Sometimes, I wonder if I could really tackle the really hard problems.

I would venture to say that most software developers have some sort of belief that they are just a regular programmer, but there exists out there some super programmers who actually do the difficult algorithms that control caches on hard drives and index search results for Google.

Now, of course there are programmers writing code that does all kinds of complex things that you and I don’t understand, but how different are those programmers from the rest of us?

Is there really a difference between an enterprise application developer and a programmer who writes search algorithms for Google and firmware which controls the mechanical operation of the head of a hard drive as it reads data from the platter?

Before I give you my answer…

Let’s talk about problems for a minute.

What is the most difficult problem you have ever been asked to solve?

How did you go about solving it?

In the end, when you actually solved the problem, did the solution seem easy?

When you go back and look at the problem, does it seem much simpler now?

Lots of questions, I know—but I want you to really take the time to think about those questions before reading on.

It is important to understand the difference between perception and reality and many software developers, myself included often have trouble distinguishing between the two.

You see, our perception of a problem is often much different than the reality of that problem.  When we don’t understand a thing, it seems much much more complex than it is.  But, once we come to understand a problem, we see how simple it actually was to begin with.

Let me give you a real example.  Take a look at this mathematical equation below.

e1 thumb The Myth of the Super Programmer

Now there are two kinds of people who will look at this equation.

  1. Those who have a decent understanding of mid to advanced mathematics and immediately recognize it and understand it instantly.
  2. Those who have never seen these symbols used together and immediately think this is some kind of complex thing that would take them years to learn.

I may not be exactly correct, but my point is there is a clear division between those who understand and those who don’t.

I can very simply explain this set of symbols to you in terms you already understand.

Ready?

That equation is the same as this code:

var total = 0;
for(int i = n; i <= m; i++)
{
   total +=  f(i)
}

So what is my point?

My point is that there are very few actual hard problems in math, programming, heck life in general, and usually those few hard problems can be decomposed into smaller problems (sometimes more than once), until you end up with a simple problem.

The point of this blog, the point of my Pluralsight videos, the point of my life, basically, is taking complex things and making them simple.

If you want to succeed as a programmer, you have to learn how to do this for yourself, because this is the single most important skill you can possess.

So, to answer the original question—No, I don’t believe there are super programmers.  I don’t believe that there is a difference between an enterprise application developer and programmers working on problems that most other programmers would perceive as really hard problems or “real programming.”

Now, don’t get me wrong and think that I am saying that I don’t think some programmers are orders of magnitude better than others.  I would venture to say that really good programmers are about 10 to 20 times as effective as just average ones.

What I am saying though is that we have a tendency to forget how simple all problems really are when they are decomposed to smaller problems and that ALL problems can be decomposed in that way.

What I am saying is the thing that might be stopping you from growing to become a really good programmer is your own false belief that you can’t possibly understand something that you currently perceive to be complex.

What I am saying is that when you write what appears to you to be a simple enterprise application, you might be forgetting just how difficult and damn near impossible it seems to all your friends and family that know nothing about programming.

Still think I am wrong?

Fine, you are entitled to think so.

But I do have a challenge for you.  Surely you know a “super programmer.”  You might even be one.  If so, let’s hear from you or them.  Tell us that complex problem that is too difficult for the rest of us to possibly understand.

I don’t even mean that sarcastically at all.  Seriously, if you can prove me wrong, do so.  I’ve just never seen a problem that couldn’t be broken down into simple to understand components, yet.

Switching Gears is Grinding Gears

Pay attention young programmers, this is the most important piece of programming advice you will ever hear.

Well perhaps not, but it might be the most important piece of programming advice you hear today.

“Switching gears is grinding gears.”

gear intro thumb Switching Gears is Grinding Gears

I’ve been doing this programming thing for quite a while now, and I have come to realize that the biggest thing that saps my productivity is switching gears.

What do I mean by switching gears?

Many different contexts

Switching gears can apply to a variety of different contexts, but it is basically whenever you are working on some task or technology and have to stop what you are doing and either do something else or change the type of thing you are doing.

This is really a bit different than multi-tasking.  Multi-tasking is really trying to do more than one thing at once.  It usually involves a large amount of rapid context switches, but for this post I am more concerned about the general idea of breaking rhythm.

I think it is easier to speak about this subject if we talk about some specific applications of the idea and why they are harmful.

Switching problems

In the Agile world of software development today, we often are required to switch from problem domain to problem domain as many of our iterations contain mixes of different features on different parts of the system and bugs to be fixed.

Have you ever been in the situation where you were just beginning to understand how some area of the code base worked, or how to work with a particular customer on a particular problem space and then had to switch to something else and start all over again?

Even when you switch back to the original context you were working with, if enough time goes by, it becomes new again.  You have to relearn much of what you had learned the last time and just when you begin to hit your groove, the cycle begins again.

This form of switching gears is at the very least frustrating, and at the most a complete demotivator and productivity sapper.

Unfortunately for most developers, this problem is out of your immediate control.  But, take note product owners and project managers, there is a reason why iterations should have a goal.

If you are in the precarious position of being a developer pinned against the ropes, try to make some noise and let your management and product owners know that your team will be much more efficient when you aren’t switching gears all the time.

In my experience, the results of replacing this constant context switching with the synergy of a common goal and related features in a segment of time has an astounding effect on productivity that is hard for any serious businessperson to ignore.  So speak up!

clss 065 thumb Switching Gears is Grinding Gears

Switching technology

This is the primary reason why I have a distaste for JavaScript.  It is why even in this abundance of web development, I would still rather program a client application.

Switching technology is painful!

This is one of those things that is unavoidable in todays development environment.  If you are a web developer, you are going to be working with HTML, JavaScript, probably some sort of server side language, and most likely some form of SQL.

It really isn’t worth trying to fight this because you are going to be going against the technology grain to do so.  Although, I do suppose this may be one of the reasons for the recent popularity of Node.js.

What we can try to do is to minimize the context switch as much as possible.  We do this by sticking with a particular way of doing things and not chasing after each new technology of JavaScript framework that comes out each week.

I’m not saying to not learn new things.  It is very important to always be learning.

What I am saying, is to try to find some kind of rhythm with the technology stack you are working with and try not to switch that up.

Technology specific training can really help here as well.  I for one, need to learn JQuery better.  The problem is that when I am working on a web based feature, I am not forced to learn JQuery because I am not in that context long enough.

So what do I do instead?

I waste time Googling for answers.  I know that I have a short coming here and I need to just bite the bullet and spend some dedicated time to really thoroughly learn JQuery, because by Googling for little pieces of it at a time, I am not really making much headway and the context switch ends up stealing what I do learn from my memory.

One more aspect of this is the idea of focused teams.  Many software development groups do not like to specialize their developers onto one focus area.  I agree whole-heartily with the idea of non-specialization. 

But!  There is huge benefit to be gained by keeping the same group of developers working on a specific set of technology or part of the code base for a set period of time.  I’ll talk about this a bit more, towards the end of this post, but the basic idea is that it takes time for people to find their groove.

I think it is optimal to break any large team up into smaller technology area focused teams that regularly rotate every 3 months or so.  The idea here is that you give those teams enough time to get good at what they are doing and actually commit what they have learned to memory, but you rotate them often enough that they don’t end up becoming specialists which are unable to see the whole picture.

Switching teams

This one typically isn’t an issue, but it can be depending on the environment that you are working in.

Teams need enough time to go through that forming, storming, and norming set of phases.  If you are constantly interrupting this process by switching around team members, you are never going to get the team to act as an entity of its own.

Teams are generally more efficient than individuals, because they benefit from synergy, when 1 + 1 = more than 2.

But just like a big truck taking some time to get up speed, a team takes time to get going.  Also like a big truck, a team can gain momentum that individual developers seldom can achieve.

A smaller aspect of this is pair programming.  I suppose that many have been successful switching up programming pairs once a day or so, but I suppose that more teams have been successful switching up pairs at longer intervals.

For me, this interval varies.  Sometimes, I feel like I need to stay paired with a teammate for longer than 2 weeks, which is our regular interval, sometimes 2 weeks is fine.  It depends on what you are working on and how much momentum you have.

They key here is to make sure that you are giving teams enough time to take up their own flag and stake their territory.  Teams can take some time to find their common goal.  Self-direction can really help with this.

The groove

Ever tried to turn a flat head screw with a screwdriver, but it doesn’t quite turn, because you can’t seem to get the head of the screwdriver into the groove of the screw?

screwdriver 1 thumb Switching Gears is Grinding Gears

You twist that screwdriver around a bit until finally it slips into the groove.  Then when you turn the screwdriver the screw turns with it.

As humans, we tend to be like screwdrivers, we have to find our groove.  We all have this adjustment period where we are fumbling through things. 

It is very important to make sure that we aren’t switching gears so often that we are not actually turning any screws once we are in the groove.

Regardless of what kind of context switching you are doing—whether it is problem domain, technology or teams—it is important to make sure that you are not spending 90% of your time finding the groove and only 10% of your time “in the groove.”

Depending on what you are doing and what the context switch is, the proper amount of time before switching contexts is going to vary, but I think it is very important be aware of this phenomenon and plan around it.  If you don’t you are going to end up spinning your wheels, which is unfulfilling to say the least.