Longer Hours in the Office is not the Answer!

Dear Fellow Software Developer,

Why does it feel like your client comes up with creative ways to slow you down? You push to release with every last drop of effort to hit the originally "promised" date... (the one forced by your boss)... which you never really considered realistic anyway?

Your energy drains away with each team reply-to-all email coming in, drip-dripping away like Chinese water torture.

Drip.

Drip.

Don't even have time to read the emails. Much less code.

Paralysis slowly settles in. You're barely keeping up with the email notifications as you're desperately trying to do another check-in.

While you may feel like you're going pedal to the metal, going home every night with your last creative juices squeezed out, odds are you are wasting away your time, energy, and even your mind...on lots of minutiae that don't matter.

You reach for various libraries, languages, and techniques in order to get more done quickly. Each time, it seems like it'll be a quick win. Yet, it never really is.

You know the drill. We've all done it before.

Some people suggest tracking your time.

Gasp.

Your boss or project manager might even insist on it for billing purposes. Yet, time-sheet tracking only makes it much worse. It's more admin.

No real benefit to you whatsoever.

What a waste of time. (How ironic!)

Drip.

Drip.

See, time is not your enemy. If you make smart use of only 20% of your time, there is no shortage of it. You're just confusing being "Busy" with being "Productive".

And productive in the context of development is never about the fricking tools. It's never about your skill with algorithms or data structures.

It's always about people, people, PEOPLE.

For example, when requirements are vague, customers will always assume "more" and developers will always assume "less." It's just an unwritten law of software engineering, which the creators of ENIAC brought down on stone tablets from a mountain. And then tried to hide them in a musky closet.

You are doing your thing, and predictably, a client needs another feature or forgot specify a nuance in a requirement. If you are in later stages of QA with code getting exponentially harder to change, it gets worse. That's how you kill development time. Fast.

Drip.

Drop.

Don't these so-called businesspeople know why they can't keep making changes and get everything done on time?

If you can manage that expectation spread well, you'll never have a problem. "Lack of time?" Merely a symptom. A distraction from the underlying issue: not being able to focus on what's important.

My name is Luke Szyrmer. I've spent years fighting with procrastination, and I've read all the books, yet most seem too vapid to be helpful to software developers. Way too much detail. Not relevant to coding. What do they know about being handed a legacy turd for maintenance? No sane person would even want to touch it. Even a microscopic tweak takes ages.

But nooooo. Who would want to listen to a developer? We can't have that....a geek running the show. What does he know about organizing work effectively?

Developers have created slick operating systems like Linux which prioritize work very effectively in real-time, packet switching networks like the Internet to manage loads in real-time, yet we're usually too timid to push back when there's deadlock among projects based on plans and estimates established last year.

As developers, we know more about managing workload than any MS-Project wielding manager, regardless of how many weekend certifications he's finished (unless he actually was a half-decent developer back in the day).

Suddenly, once you see the analogy, multi-threading issues take on a completely new meaning. Look at organizing your own work as system. Why wouldn't you want to use the basics of parallel processing to deal with incoming work requests?

Work usually arrives randomly, all at the same time. You're relatively idle for a couple of weeks. Then, out of the blue, you get 9 major issues and features in the same week... It almost seems like your customers communicate with each other in smoky back rooms. Better. Via psychic connection.

In order to be productive, you need to have the right system in place. Your code needs to be built in accordance with simple, specific technical practices which you know but may overlook. You are an expert in building systems. Why not use the same skills to ensure you work as productively as possible?

If you have the right system in place, you can work less than half the time you do now. You can experience more overall output - much more - if you think harder about cost/benefit relationships before banging out code.

There is just one thing you absolutely have to understand, as it affects your productivity immensely. You don't see it. You can't touch it. Yet you know it exists.

Dependency injection. The ability to say no at any time, including at run-time, forms the basis of strategic coding.

While it might take a bit more effort, it means you are free to experiment and discover the optimal approach - in real-time. Not only in your code, but also in how you organize your work with other people.

It's what makes you truly agile, able to respond to change.

If you are unable to respond to feedback, or avoid getting feedback in the first place, you lose the ability to sharpen your skills. To deliver software.

See, feedback is a fundamental force. Evolution requires feedback. Natural selection ensures that the best adaptations survive. We can speed things up by intervening, and making sure we like how things improve.

Ultimately, it boils down to properly functioning feedback loops. Information that makes your architecture more robust. Information that strengthens your organisation as the pace of change increases. Information that helps you make tactical coding decisions more effectively.

Given enough time, feedback loops turn level playing fields into lopsided distributions. This is why 19th century engineer-turned-economist Vilfredo Pareto famously discovered that 20% of his pea pods yielded 80% of his peas. That 20% of his contemporaries held 80% the land, the primary source of wealth in his time. He started seeing the same relationship in many places. He posited that this happens everywhere, because it's an optimal equilibrium, certainly from an economic efficiency standpoint.

While the numbers do not always hold up exactly, that same inequality occurs whenever feedback loops occur.

Even the internal combustion engine: 80 percent of the energy is wasted in combustion. Only 20 percent gets to the wheels. This 20% of the input generates 100% of the output.

The occurrence of crime in cities follows an 80/20 distribution. The NYC police department used this principle to reallocate their police force disproportionately where there were broken windows--resulting in a much safer city.

In most buildings, 20% of the carpets get 80% of the wear and tear.

Think this doesn't apply to software, the internet and programming?

• the popularity of websites (most internet traffic goes to sites with highest alexa rankings)
• the fact that about 80% of readers only scan the headline and 20% read the whole web page
• the frequency of file check-ins of files in un-refactored code bases with "god classes". 80% of your code in 20% of your classes.
• IBM famously discovered in the 1960s in their operating system, that 80% of processing time occurred in 20% of the code
• bugs tend to occur in clusters...if you find one, it's likely there are a number of bugs around it. 80% of your bugs occur in 20% of your code
• and the list goes on and on and on...

I'm not making a judgement call here, about what should or shouldn't happen, or whether it's fair. I'm just pointing out that this happens a lot more frequently than we care to acknowledge. Anyone who pretends that this isn't the case is not only fooling himself, he's he's wasting serious amounts of time. There are a handful of techniques which help you adjust your work, and get a lot of effect for very little extra effort.

That's why we're never really out of time. We are constantly wasting it on minor, relatively unimportant things. Instead we could be using feedback to strengthen what's best about our code and our product. Without actively seeking out feedback that validates our assumptions, we live in a bubble of our own creation. If it turns out that our assumptions are wrong...ouch.

In fact, what's the whole point of being either agile or lean? To evolve faster than your competitors.

See, Charles Darwin observed that "adaptations in domestic animals are usually adaptations which are beneficial to Man". He goes on to claim to claim that "hardly anyone is so careless as to breed from their worst animals." Too bad we don't do that when evolving software.

In software, we don't explicitly think about our code as an evolving system. As a result, we've lost the opportunity how to "breed" our code consciously, while making the best use of time as we iterate. Create something truly impressive and valuable.

In reading this book, you will discover how to apply the powerful 80/20 principle in order to:

• Make Pareto-optimal decisions when facing design trade-offs in your code.
• Hack your company culture to introduce changes which spread and mutate the culture effectively, so you can focus on building software
• How to shrink the gap between what clients say they want, and what they actually want
• How to deal with legacy code and maintenance work, so that you are certain you increase your productivity the longer you work on it
• Get the most you can out of meetings you have to attend, in order to stop making them feel like a waste of time
• Grab the attention of decision-makers, so that people listen to you
• Design products so that they are attractive and they scale by being attractive to early adopters and the rest of a market
• Create high quality code without necessarily writing thousands of tests which prove what you already know
• Ensure that your code always remains easy to modify and understand
• Deal effectively with sudden spikes of work, without hurting the rest of your delivery schedule.
• Avoid wasting your time creating code no one ever even finds.
• Spend as much time as possible creatively solving real-world problems.
• Make it easy to get rid of dead code.
• How to increase your productivity massively, even if you do have to track your time

The secret lies in managing your productivity, as opposed to your time. Everyone gets the same amount of hours, as everyone else. But it all boils down to how we construct our usage of that time.

This isn't a vague fluffy theory, where you need to tap your nose and sing Kumbaya while hugging your team. The 80-20 rule solves your real-world productivity problems for developers, so you feel significantly more effective. It's been around for over a hundred years, applied to lean manufacturing reaping massive results. Pareto was originally trained as an engineer, after all.

The exact numbers of 80 and 20 aren't actually that important; the fact that they are lopsided, is.

This book will connect the dots for you. It spans a number of disciplines, tying them all together for your benefit, so that you are clear on how you can ramp up your productivity without memorizing another shortcut.

Of course, it takes a special individual to fully appreciate the implications of the 80/20 principle. This book makes it much, much easier to become significantly more productive as a developer. It cuts through a lot of BS, so that you aren't mired in pointless details. Even though the 80/20 rule's easy to understand, not everyone has the guts to use it.

Time is not the enemy. If we make good use of only 20% of our time, there is no shortage of it.

In fact, to benefit from this book, you won't need to do everything suggested in the book. By implementing at least two things from this book, your productivity should be measurably increased!

I Guarantee They’ll Spike Your Productivity And Drop Your Stress 10% In ONE WEEK after implementing at least 2 of the changes suggested...Or Your Money Back.

That means you receive 100% of every penny you paid back. No hassles, no hard feelings.

Not only that, if you can document at least 5 things you tried from this book and why each didn't work for you, I will give you an additional 50% of the price back. That's 150% of the original purchase price. You end up making money for buying this book. That's how strongly I believe in the value of this information to help you.

For 39.95, you'll get the full ebook, a fast action checklist containing all of the main action items, and access to additional materials to help you get started over the first few months.

Buy Now XXXX

P.S. You won't find this level of depth on using the 80/20 principle in software anywhere else. I guarantee that too.

P.P.S. Learn to focus on things that matter. That may seem intuitive and even painfully obvious, but I promise you almost no one figures this out without some help.