Anonymous MSFT developer admits Linux is faster than Windows →

May 12, 2013 by Leave a Comment

Well, if you’ve used Linux for any length of time and compared its speed to that of Windows, this was a no brainer. What’s damaging is that this Microsoft OS developer brings to light just why Linux is faster. Not only does it show that Microsoft is misguided and in trouble if they keep going down this road, but it alarms me that they don’t give a shit about their operating system.

You know, the operating system that millions of people pay for their businesses to run mission critical applications and mail servers on. The operating systems that Microsoft charges asinine amounts of money for.

I wish that Linux would become much more viable in the next few years, and that major software vendors start to switch to if. In other words; I’ll keep dreaming.

★ Link
Filed Under: Development, Technology Tagged With: , ,

A Toolset for a Productive New Year (2013 Edition)

January 5, 2013 by Leave a Comment

Another year is here and it’s time to get serious about the tools I use to get my job and life done. I try every few months to “downsize” what I use; but I am coming closer to the realization that I don’t have to be “minimal” to be effective.

I simply need to make sure that each tool in my toolset has a use and that I use it. That’s all.

Last year, the 2012 Edition did pretty well here at DevBurner, so hopefully this will provide some more fodder for you tool hungry fools. :D

Here we go.

Paperless and Automation

I love, love, love David Sparks newish eBook about going paperless. I am finally finding the correct workflow with:

  • ScanSnap S1500 an amazing, duplex, you-need-this-now-so-don’t-wait scanner.
  • JotNot Pro on iPad and iPhone for mobile scanning.
  • Evernote and Skitch for keeping track of notes, screenshots, etc.
  • GoodReader on iPhone and iPad. This is the way I manage files on my iOS devices. It has a little feature overload, but it really does do everything I could ever want.
  • Hazel. I don’t know why I didn’t buy this sooner. Hazel basically automates all kinds of actions on the contents of a folder. My paperless system wouldn’t be as efficient without it. I’m barely cracking the service with this app and will be writing about it more and more this year.
  • Launch Center Pro for iOS is a great little app that makes certain tasks on your iPhone much faster and found under one roof.

Productivity tools and systems

I found out this year that I’m flaky when it comes to productivity and “GTD” applications. While writing for Lifehack, I tried so many different todo and project management apps and thought that the new shiny one with the new shiny features was going to somehow improve my productivity. It didn’t. So, I’m going back to my rocks in 2013; using these systems and apps as support mechanisms above anything else.

Development Tools

At my full time job I’m a developer about 75% of the time. So, I have to make sure that I have tools that I can use to get my job done faster and easier.

  • Visual Studio 2012. Programming on Windows? Well, then you will need this. Actually, I really like Visual Studio. Also, with the new addition of LightSwitch to the VS family of tools, I have found that I can get a ton more done for my end users.
  • Kendo UI for all the newer web apps I’m creating. It’s a great JavaScript framework and helps me not have to lean so much on a gazillion different libraries.
  • Knockout.js for using the MVVM pattern for web UIs. Knockout is a great tool to use to build single page applications with JavaScript and HTML.
  • [Bootstrap] is a front-end framework made open source by the peeps over at Twitter. It’s a great way to get a web app up and running and looking good at the same time. It can be (and should be) used as a framework and then customized.
  • Sublime Text 2. From a huge IDE to a nice, fast, fun editor. What I love about Sublime Text 2 is that it’s fun to use and works on Windows, Mac, and Linux.
  • Git for version control.
  • Ruby on Rails for my personal web development and projects.

Writing and reading tools

I’m going to be doing some more writing here and in other places across the web this year. It’s important to have some trusty writing tools so I can get an idea down as soon as I have it. Also, I read quite a bit so having a good workflow for that is essential as well.

  • Instapaper. The best way to save articles for later and read them without any distractions. Works perfectly on my iPhone and iPad.
  • Reeder. I tried to get away from Google Reader this year, but I just kept coming back. Reeder is the best and most fun way to read RSS feeds on my Mac, iPhone, and iPad.
  • Byword for Mac and iOS. I’m writing this post in Byword now. It supports Markdown and not a lot of features. I love it for writing things between 100 and 5000 words.
  • Scrivener for long form (greater than 10k words) writing. I’m going to write a book this year. Scrivener will be my companion in that journey.
  • Drafts for iPhone and iPad. I love this app because it’s fast and I can send my text almost anywhere I want to. It’s replaced all text editors on my iPhone homescreen. I just start with Drafts and go from there.
  • Day One for Mac, iPhone, and iPad is an amazing journaling application. It’s made me want to journal for a whole year now. I will continue with it.

That’s it

That’s a lot of tooling. But I know for sure it’s not everything. There are so many little utilities and workflows that I use throughout my day that I’d bore you (and possibly myself) with all of the details. These are the heavy hitters and as the year progresses I will talk about them and others in depth.

Whatever tools you choose, remember there are just tools to get a job done. The job is more important than the tools used to do it. Hopefully there is something on this list that can help you in 2013 get more important work done.

Filed Under: Productivity Tagged With: , , , , , , ,

BaBSE 9: Know Your Tools

August 31, 2012 by Leave a Comment

Being a good software developer means that you can create software solutions that help solve problems quickly. Being a software developer doesn’t mean that you know every little nook a cranny of a language or every design pattern on earth (although, this can help and is something I personally need to concentrate on), but it does mean that you know how to use tools to create solutions for people effectively.

There is a whole market (free and paid) for development tools that help developers get stuff done in their work lives. And of course, there is a multi-billion dollar app and software market that has been around for decades. These are all tools that help people create and get their jobs done. But is it really only about the tools that you use to develop or to get things done?

You are only as good as your tools

This idea of only being as good as the tools you use to make things is pretty right on. This can be a fine line though. Some people think that you need a super-mega tool to get things done (for instance a full blown SAP implementation for Enterprise Resource Planning) opposed to something that has just the right amount of features you need (where I work, this is an ERP system called JobBOSS).

I think that rather than saying that how good the tools you use dictate how good you are at programming, planning, writing, etc. it should be more along the lines of:

You are only as good as the tools you know

This notion says that it doesn’t matter exactly what tools you use to get things done, but that it’s more important that you know the tools inside in out. So, whether you are using a full blown IDE or a simple text editor to develop, it doesn’t really matter as long as you know the tool and can still develop solutions quickly and effectively.

While developing on Windows I use Visual Studio because it’s pretty much the only tool that I need (and can use) to make Windows and ASP.NET apps. There is a ton to learn about Visual Studio itself, but once you get past all the knobs and switches you can be incredibly fast and productive with it.

It doesn’t stop here

Being only as good as the tools you know isn’t just about software development; it works with productivity, writing, reporting applications, document creation software, etc., so this can apply to anyone that deals with any type of toolset in their work and life. As you get further and further into developing software and solutions you will find that it isn’t about the tools that you use, it’s about knowing what you need to get the job done and then finding and learning tools that support that. So, maybe it’s time to stop looking for tools to make you better, get better and then find and learn tools that support you.

Filed Under: Development Tagged With: , , ,

BaBSE 7: Perfect Planning Doesn’t Exist

August 24, 2012 by Leave a Comment

I’ve been “working” on a web app for sometime now and will use it as my “calling card” moving forward. It’s just something small and effective that I need to create to ship something into the world, to break the ice, and to create a platform to build off of.

The problem is that I plan too much, too often, and when I get stuck planning the application, I freeze and don’t do anything. But, it doesn’t have to be that way for technologists and software developers.

Big systems

When I was working for a large insurance company we had some intense project planning going on. Timelines, small project packets (200 pages isn’t small though), meetings, meetings, and more meetings. It felt like overkill, but, in reality was probably an important thing to do for the complexity and depth of what was going on with different pieces of software, not to mention we had to make sure that regulatory and certain legalities were taken care of. Some of these systems were 20/30 years old and we were integrating new stuff with them which added another portion of complexity.

This type of in depth planning is mostly needed for large systems (although, some of the meetings were a complete waste of time). But, even those these plans that are in a perfect little Gant charts, created with picture perfect white board sessions, and detailed in small project packets with code and comments aren’t perfect and sometimes completely fail.

Small systems

With smaller systems and apps we have the choice to not go into as much detail when we plan. We can get away with skipping complete plans and timelines and concentrate on smaller, more concise plans that actually mean something. Here are two awesome resources for planning software:

  1. Painless Function Specifications Series from Joel on Software

    If you want to do a little more in depth planning, this is the way to do it.

  2. Getting Real by 37signals

    If you want a “no-BS” approach to making quality software without the overhead of planning too much, this is the way to do it.

Here’s the hit

If you are planning large or small systems you can’t do it perfectly (even with the awesome resources above). You can get close to creating accurate plans, but it’s never perfect. So, instead of spending the time to create a plan that is “iron-clad”, spend less time making a passable plan and then start creating. When you hit a brick-wall with your plan or things don’t match up with your plan then change your plan.

What tends to happen, at least with this technologist, is that I plan some software (mockups, requirements, small functional spec, etc.) and when my actions start to go outside of the plans, I start to think that my plans are “wrong” and then scrap them. That’s not how it should work. We have to remember as technologists and developers that plans will change, especially for small or medium size systems and even more so when you don’t have any sort of hard requirements (like legal or regulatory).

So, rather than plan for perfection and think that you have failed when plans change, plan for change and understand that your systems will never be perfect even after the system has shipped.

Filed Under: Development Tagged With: , , , , ,

BaBSE 6: Knowing When to Say No

August 17, 2012 by 3 Comments

Solving problems with systems and software is a tough job. And it gets tougher when you have users dipping their phalanges in the system that you need and want to create for them.

Common things you will hear during the software development process from users are, “yeah, that’s great, but…” or “well, I thought it should work like…”. If you have been developing for any time at all then you are probably accustomed to this behavior.

Don’t hate the player, hate the game

It’s not the user’s fault that they want a billion different things in a new system. They simply want an awesome system to do their job and make their lives easier. But, there is a little term that called feature creep that destroys developers’ lives. This is the idea that as one new feature gets added to a new system, then ideas start flowing and other features are suggested and then “needed” by users.

This is the “game” of defining features for systems. You have to be good at this game to make sure that you don’t design a system that has a million functions, looks amazing on paper, and then will never be developed because it is too much work.

Brainstorming

It’s never a bad idea to sit around the table with some users and come up with a bunch of potential features for future systems. This allows everyone to work together and bring their different background and perspectives to light. This is a super important exercise in the software development process and shouldn’t be avoided because you are afraid of feature creep.

But, what tends to happen is that users (and developers) get this idea in their head that all of their good ideas will be put into reality. This is dangerous territory.

So, to make this game better, make sure that when you are brainstorming ideas for systems, that you and everyone else knows that this is a brain dump of ideas, nothing more, nothing less. Don’t say no to particular ideas in the process. Instead, come at it from the perspective that none of these ideas “are the system”. These ideas are just ideas.

Saying no

Saying no to particular features of a potential system is the most important part of developing a system that will actually work. I work in a team of 1 where I work and because of that I have to say “no” a lot. All ideas are great ideas until you look at the details and realize how much work they will actually take to implement.

I can’t remember the exact saying, but it basically goes like this: However long you as a developer thing something will take to create, convert it to the next time unit and multiply it by 2. So, if you think a feature will take 2 hours to implement, you should say that it will take 4 days.

The numbers don’t really matter. The point is that new, awesome features take time and resources to create. If you don’t have the time and resources, then you have to say no to things that aren’t “core” to the system. This can be a painful pill to swallow, especially in a corporate environment where sometimes saying “no” is not an option.

When to say no

So, when can you say no to something? My best advice on this is that the only real time that you can do this is when you have worked with users and stakeholders of the system and identified all of the “potential” features. With that raw information in front of you, you can pick the top 5 features that you have to implement for the system to be the system. Everything else is a no until those 5 features work awesomely well.

The number 5 isn’t necessarily a hard-and-fast rule. The idea is that you are taking a workload of development that by the end of it will produce something that is worth something to your users. Yeah, they may not have all of their amazing, whizz-bang features that they were hoping for, but they have something that is usable. Other features can come later.

So, you have to say no a lot, especially in the beginning of a project or if you are strapped with little resources (raises hand).

Here are some other really great posts/books on this topic. Just remember implementing features is all about what you can handle and get done. After a couple of years you become much more realistic when it comes to timelines and what you can handle as a technologist.

One last thing, if you didn’t make the connection, this saying “no” stuff isn’t just about software development. You can use the idea of creating boundaries and doing just the right amount of stuff when it comes to productivity as well.

Filed Under: Development Tagged With: , , , ,

It Ain’t Easy Being a Creator in the Post-PC Era

March 8, 2012 by Leave a Comment

In case you missed it, a company from sunny Cupertino, CA announced a new product yesterday. The new iPad is said to amaze us and push consumers further into the post-PC era.

The post-PC era sounds all fine and good for the consumers out there sucking up content, replying to emails, and looking at photos, but what about creators? Are they left out of the post-PC era, or can they (we) too use post-PC devices and ideas to create content, products, and things that change our world?

For the creators

I remember when the first iPad came out. Many tech pundits and media said that the device what a “consumption-only” device because of its lack of a physical keyboard, camera, etc. No one could really create anything on this thing. Then we saw

Creators need tools that can react to input and changes immediately[1. Thanks to Mr. Schechter for the link], showing them what they are in the process of creating. Creators need tools that are ubiquitous and easy to use. To think that someone can’t possibly create something because they aren’t “doing it the hard way” is starting to be an annoying remnant of curmudgeons that are showing that they are afraid of the future.

The new tools like iPhoto, iMovie, and the iWorks suite show us that we can use thin, light, and “limited” devices to create. We are slowly seeing that we won’t need bloated devices, 8GB of RAM, and spec crazy devices to create with.

The fact is that creators want tools they don’t have to think about and that get the job done. If it is in the form of dictating to an iPad, using a Bluetooth 4.0 pressure-sensitive stylus, or just a plain old wireless keyboard then that is awesome. If technology is reducing the friction of creation by giving us easier and more beautiful tools to use, then that is the new way to create.

What about programmers and technologists?

Programming on the iPad (or any tablet/post-PC device) is a bit of a bear and something that hasn’t been fully paid attention to yet. Other than remotely connecting to another PC, Mac, or Linux box and using your device as a dumb terminal, there isn’t really any way to compile and create software directly on the device. Other than programming, tasks like creating documentation, project plans, flow charts, business proposals, etc. But this is mostly “administration” type of work, not technological creation.

As of now, technologists and programmers are still tied to their Macs and PCs until there is a good way to incorporate all of their powerful tools on a post-PC era type of device. Sure, we can use remote facilities of our devices to program, compile, and even push code out for consumers to use, but there is not yet a way to do all of this natively.

In due time.

Being a creator now

It’s not easy to be a full-time, post-PC era creator. But neither is being a creator, developer, or technologist in general.

This is a new time and place and we are still feeling it out. It’s still the early days and as of now, it appears much easier to be a consumer. The tools will definitely get better as we the creators demand them and create them for each other. So, don’t give up your MacBooks and PCs just yet; the post-PC era isn’t fully realized for technological creation.

Filed Under: Technology Tagged With: , , , , , ,

Face Your Fear of Failure With Technology and Start Building

February 27, 2012 by Leave a Comment

It’s easy to get into a non-productive, fear-induced rut, especially when it comes to creating something with the infinite amount of technology we have today. We start to think that the tools we have aren’t the right ones to get the job done, the processes we have in place aren’t efficient and “setup correctly”, and the idea we have isn’t quite right.

I have been throwing some ideas around about a new piece of software that I want to create for the web, iOS, and Android for some time now. But, I tell myself I just don’t have enough knowledge to make it happen. What it really comes down to is me not having enough guts to create something and be OK with it if it is a failure (which it probably will be; at first).

Rather than being afraid that you don’t know enough, or that you possibly couldn’t create what you wanted to create, I’ve found some guidelines that have helped me break through the fear of failure and start building.

You know enough to get started

I constantly convince myself that I need one more tutorial for a certain framework or programming language before I can get started on projects. I tell myself I don’t know enough yet to make a good application that people will want to use. The problem is that I always think that I need one more tutorial to make my ideas turn into usable apps. There is nothing further from the truth.

The problem that many developers and creative people have is they think that they don’t have enough information to complete what they want to create. The truth of the matter is that you may not have all the information that you need to complete your creative endeavor, but you sure as hell have enough to get started. So, get started and the pieces will fall into place.

Pick a technology and stick with it

A good technologist knows how to use a toolset to solve problems. The problem with that is picking the toolset. I have been going back and forth on what technology to choose for the application I want to develop. Should I go with Ruby on Rails, something that I’m not extremely familiar with, but familiar enough with, or should I stick with what I know now?

Unless using a different technology is part of the app being successful or you really want to try a new technology with a new project, then stick with what you know. This reduces the barrier to get started.

You will probably fail, so do it now

My biggest fear is that I will make something and no one will use it (except for me of course). But, it’s really the beginning of the last sentence that is the problem.

“My biggest fear is that I will make something…”

Anything after that is just part of the problem. I’m afraid they will hate it, I’m afraid it won’t look right, I’m afraid of everything about it.

The reason that we have this fear of failure is that something in the past is giving us false evidence today that our worst fears will be imagined. I’m here to tell you (and myself) that you will probably fail, at least at first. So, instead of being fearful of failing, at least create what you can, fail, then iterate. You will be better and stronger for it in the long run.

Besides, technology is so awesome now that you can write a book, create a new app or game, or movie with hardly any cost other than your time. You aren’t losing anything when you fail; you are gaining the incite of what will and won’t work.

Everything will fall into place, as long as you let it

So, rather than fear that you don’t know enough, aren’t tech savvy enough, or will fail miserably, simply move forward and figure it out as you go. You don’t need a crazy GANTT chart or in-depth requirements document to start creating something. You don’t need expensive tools and special processes to make things happen. What you need is some standard technologist skills, time, and the lack of fear of failure.

Now, instead of searching for one more article, trying to find out how to lose the fear and create things, just go create things.

Filed Under: Technology Tagged With: , , , ,

Ubiquity is a Feature

February 20, 2012 by Leave a Comment

Are you a Mac fanboy? A Windows “Power User”? Do you scoff at how “zealots” tote around their iThings and disregard anything and everything else as being a viable option? If so and you are a developer or creator of software, you may want to take a step back and consider including the “ubiquity feature” in your apps.

Cross platform app development is here to stay. So, rather than disregard it, use it as a feature of your software.

Other OSes exist

I have had quite the transition from Windows user, to Linux user, to Windows “power user”, to Mac, to anything under the sun user. What I still find hard to believe is that some developers only offer their software for certain “platforms”, even with the availability and growing power of creating a web and mobile applications. The fact is that there are other OSes in the world.

Many Mac aficionado tend to think that there are only Macs in this world. As Apple has been making a killing lately with iOS and even with OS X, we have to remember that the majority of people on earth run Windows. This of course will probably change as Microsoft has been digging their own grave for well over ten years now because of their stagnation, but the fact remains that there are many OSes and platforms out there to support.

We should plan for them

There may be a number of good reasons why developers create software for a certain platform or another, but if they are creating frontward facing services for end-users, it seems like a real misstep for them to not use web and  HTML 5 technologies to make their apps available to all.

Developers (especially fledgling ones like myself) should plan for this. Rather than develop apps for a certain platform, we should be opening them up to anyone and everyone. We are limiting ourselves because of lack of experience in a platform or just plain “zealotness”. At the very least, developers should offer robust APIs so that other developers that have an interest in a certain platform can interface with their software.

Cases and points

One good example of a software company that is doing this right (other than the whole not charging anything part) is 6Wunderkinder. They used Appcelerator’s Titanium products to make Wunderlist available online, for Mac, Windows, Android, and iOS in record time. And for the most part, everything works without a hitch. We can argue whether Wunderlist has the features that one needs for tracking their todos, but what we can all agree on is that in this case Wunderkinder has made ubiquity a feature.

Twitter is a great example of an app and service that made a great API for developers. This can be argued to be one of the main reasons that popularity for Twitter grew so quickly.

Another good example of this is the webapp Toodledo. It may not be the most grand, exciting, or pretty app, but Jake at Toodledo has done a hell of a job of making his app ubiquitous as well as created a great API so third party developers can create applications that work with it. Yet another is the new app Asana (one that a good friend has adopted over an app that can’t be used cross platform) which has a very responsive web interface. The mobile app is sort of lacking, but new additions are made consistently.

Other apps like OmniFocus (or anything from the OmniGroup), Microsoft Office (although it’s getting better) and others are limiting themselves by not giving users the ubiquity feature or decent APIs for third party developers. These developers may scoff and say things like, “well, you can’t get real work done on a Mac anyways (yeah, that’s you M$),” or “we want to only cater to the Mac platform,” but the fact is that the OS is becoming less and less important with the availability of the web and the growth in the power of web and mobile technologies.

Conclusion

I can’t say that apps that are only for iOS or Mac or Windows won’t do well (because apps that are only for those platforms continue to do well). What I can say is that ubiquity is a feature, that cross platform app development is important, and should be added to any new application that is being released. Whether the apps are ported to a specific platforms, available on the web, or have an API that other developers can access, developers need to pay attention and make their apps accessible from anywhere at anytime.

Filed Under: Development Tagged With: , , ,

Become a Technologist, Not a Specialist

February 13, 2012 by 3 Comments

My first job out of college last year was a Programmer Analyst position for Erie Insurance. I loved going into work, programming most of the day, and solving problems. What I came to find out though was that I didn’t want to be pigeonholed as “programmer” or a “developer” my entire life.

I wanted to be able to do more, learn more, and be more versatile in the IT field. Instead of being a specialist, I wanted to become a technologist.

What is a technologist?

According to the dictionary definition, a technologist is:

a person who specializes in technology.

That’s a little too vague for us. For us, a technologist is someone who specializes in the IT field, works on a computer most of the day, and wants to create businesses, software, and services with their IT talents.

Don’t limit yourself

Some people may think that if you are a generalist rather than a specialist then you aren’t good at anything; just kind of good at everything. This is a terrible way to look at it.

Why can’t someone be good at programming, design, understanding networks, and administrating servers all at once? People can be, and they are doing it all the time.

Sure, you can concentrate on one or two things and get really good at those things, but without the basis in everything else tech, then you are limiting yourself. So, don’t do that. Rather than being a specialist you should try to become a technologist.

It keeps you sharp

Being a technologist pushes you to learn new things all of the time. If you aren’t continually learning and improving your skills, then you are back pedaling and becoming antiquated. In the tech field, there is nothing worse than feeling and being antiquated, that is, unless you don’t really give a shit about your job or are just collecting money to pay the bills (which wouldn’t be in the technologist’s spirit).

Striving to have a general backbone of technology knowledge is a hard thing to do, but doing so will keep you sharp and wanted by companies, as well as give you the freedom to start your own business ideas because you can do a lot of the stuff by yourself.

It keeps you interested

Sure, if you specialize in something you can get really very good at it, possibly be the best at it, and die doing it. But, what about all the other fun and exciting things you can do when it comes to the IT field?

If I’m a straight DB Admin for a large company, I can’t just say, “hey, I think that I want to design the interface for our new customer-facing web app.” Even if I wanted to do this sort of thing, most companies would require that I have several years experience in front-end development and blah, blah, blah.

Generalizing your base tech skills will help you stay interested in the field. Sick and tired of learning about networking? No problem. Take a look at some jQuery and use it to build a more dynamic site.

How to do it

Rather than concentrating on one aspect of IT you should get a solid, base understanding of the following 7 things to become a technologist:

  1. Programming
  2. Computer hardware, software, and networks
  3. Design
  4. Usability and user interaction
  5. Business
  6. Communication
  7. Creativity

With these you are well on your way.

When it comes to any of these disciplines you don’t have to become the next great software developer or a Steve Jobs type of businessman (although you may). What you will do is become very familiar and comfortable with the above disciplines and then start to concentrate on one or more of them going forward. You will also make sure to keep up with new trends and developments with the 7 aspects in the years to come.

You can’t just learn these things once and call it good. You have to keep up with them to consider yourself a technologist.

Conclusion

Being a specialist isn’t all it’s cracked up to be. By being a specialist you run the risk of not challenging yourself enough, not keeping up with the times, and becoming antiquated.

By becoming a technologist, you will become well-rounded and give yourself a basis of technical and business knowledge to further your skills in the IT field. As I’m making the journey to become a technologist myself, we will revisit these 7 aspects.

Edited on Saturday 18, 2012 – I realized that one thing was missing from the 7 Aspects of Being a Technologist. Creativity. Instead of going to 8, I decided to put networking in with computer hardware and software.

Filed Under: Technology Tagged With: , , , ,

Becoming a Better Software Engineer 3: Know Your Productive Times

January 7, 2012 by Leave a Comment

I subscribe to the GTD methodology of project planning/tracking and life management, and while GTD is great for keeping all of your “stuff” in work and life under control, it does sort of fall by the way side when it comes to planning your day around your most powerful times.

A good book about the concept about knowing when you have the most energy as well as how to create it is The Power of Full Engagement by Jim Loehr and Tony Schwartz. This book explains that time isn’t the key to productivity; it is understanding and exploiting when you have the most energy. The problem with the software development field, especially that of a normal corporate setting, is that technologists are expected to get their coding done between a certain set time. That may be fine for some, but for many these aren’t their productive times. Especially some developers that rely on late nights and caffeine.

So what to do?

You have to find your most productive times as a developer. Not only the times that are good for actual coding, but the times that are the best for design, bug tracking, bug fixing, documentation, meeting and brainstorming with users, and, if you have to deal with it, mind-numbing paperwork. For me, there is no one time that is good for any of these, and I have to make sure that I split them up during my day to use my energy for each type of work specifically.

How to do it

Are you better at coding in the morning? Late at night? What’s the best time for creating documentation of your code? You have to find when you are energized for different types of of development work.

The best way to do this is simply to keep a log of your days. Do this for a week. Basically just make a list of the tasks that you have done, the time of day, what your energy level was, and how you felt doing it. I tend to just say I have “low” or “high” energy (binary is always better). You can then take a look at this data at the end of the week to help you decide when your best times for certain tasks are.

The next step is to take this new found data (boy, is it valuable!) and block out times on your calendar that coincide with the times where you have the most energy to get certain types of tasks done. This may be difficult, especially when you can’t or don’t make your own hours, but you can at least start to create a framework for using your energy to develop and do technical work more efficiently.

Why do it?

Knowing your productive times to get your technical work done not only helps you get more done, it allows you to get it done with the least amount of effort, freeing up even more energy to create new and better software or ideas related to current projects. Rather than force yourself to get something done, especially during a time of day or night that you don’t want to do it, it’s much better to put a little investigation time in to see when the best moment of your day is.

[Photo credit: Danemusic via flickr (CC BY-NC-SA 2.0)]

Filed Under: Productivity Tagged With: , ,
«Older Posts