Category: Development

You are good enough

continous improvementKaizen. It’s a word that  I learned a long time ago. One that I have tried to apply every single day.

“Japanese for “improvement” or “change for the better”, refers to philosophy or practices that focus upon continuous improvement of processes in manufacturing, engineering, supporting business processes, and management” – Wikipedia

With regard to programming, continuous improvement is the name of the game. There are tons of libraries coming out that for me, can get a bit overwhelming. It can sometimes feel that if you don’t know about X library/framework, you will fall off into the blackest hole of the universe and have “everyone” ahead of you. It’s especially painful when you are doing your best and some eight year old is developing software you only wish you could.

It’s ok, you are good enough and will only get better (if you want to).

If you do any form of programming development, kudos to you. This field is not easy. There are some incredible minds out there that continue to blow my mind with what they put out. This does not dissuade me from crafting my art, it only inspires the limitless opportunities of what is possible – what I can make possible.

We are all students. There is always an opportunity for to learn something new and/or strengthen our current abilities. For me, having the student mentality keeps me on my toes and allows me to be humble. Sure, there are “experts” out there that everyone respects. They’re “internet famous”, have tons of followers and are considered the top in their field. I have much respect for their accomplishments. That being said, they were once also considered a “novice”.

We all start out sucking (literally). Then we get better. Then some of us are satisfied just to get a paycheck.

Then there are those who want to improve, no matter what level they are in their field.

That’s where I am, and that’s where I think all developers should be. Keep your mind fresh and your head high. The world is at your fingertips.


Nicholas Zakas recently posted his slides from this past weekend’s jQuery conference. Among the great information provided, one slide (#74) really made an impact on me. It basically sums of the fact that browsers vendors, like televisions sets, are consumption devices. Much like TV’s, the producers (web developers) of shows (websites) create a product to be served to all kinds of devices.

Here’s the difference: television producers don’t give a damn what television you are using when watching their program.

Whether you have an old school TV that weighs 300lbs or an HD TV that weighs 50lbs, you’re still watching the same show. Sure, the quality is different, but it’s still broadcasting the same exact way (albeit HD is a higher quality). If it were only that easy as a web developer…

From IE6 to Firefox4 and everything in between, we have to make sure web pages look semi-decent for our users. But

No. Hell to the NO. A resounding no effing way.

Yet still we try our best to accommodate for such nonsense. From conditional styling via clever commenting to JavaScript browser sniffing, developers are trying their best to make web content look, and in some cases preform consistently.

“Don’t worry, HTML5 will fix that”.

No. It won’t.

Why? Do I really have to go there? OK, fine..

  • It’s not fully supported on all browsers and won’t be until after the apocalypse.

There. That’s why.

And even when the spec is actually finished, all vendors still need to get it together and comply with the new rules.

Until then, what do we do? We sit at our desks and punch keys all day in order to accommodate for the dinosaurs that are still using IE6. And it’s not only IE that’s the pain in the ass, every browser has their quirks.

Is there a solution to this never ending quest of consistency? Hmmm…

  1. One world browser: That’s right, have only 1 web browser that EVERYONE MUST USE.
    No, that won’t work. It didn’t (or did it..) work for the New World Order, and it won’t work for browsers.
  2. EVERYONE uses the same operating system.
    Nope. Microsoft tried that, look how well it worked out.
  3. Turn off the Internet.
    Yes we can!

With the wide variety of available devices that are able to render an HTML page, it can be overwhelming to think of all the possibilities of how crappy your website will look. I’m convinced that no matter how hard you try, there is a browser out there that will make your webpage look like it was designed by Helen Keller. Hell, just ask your Quality Assurance (QA) team.

Which brings me to my point –  different browser, different experience – get over it. Your QA team needs something to do. What better avenue then to bring up minor discrepancies between browsers.

QA: “This element should have 1px margin more on the left, but only in IE6/7. Other browsers need 2 more pixels. And don’t get me started on how it renders on the iPhone… and Android… and Nook… and Kindle… and <your browser here>”

WTF. Really? How about I take a pen and jam it directly into both of my eyes.

I demand that we (developers) get access to what percentage of users are using specific browsers. I, like many web developers, have spent countless hours on debugging outdated browsers for the most trivial bugs in imaginable.

If less than 5% of your users are using a browser that you spend more than 10% of your time debugging, IT’S NOT WORTH IT.

But hey, if they want to keep paying developers to waste time on such nonsense, show me the money.

As a developer, it is crucial that the client/employee clearly defines what they want. Specs can come in many forms; written, screen shots, interactive, a combination of those and other techniques; whatever it takes to get the message across clearly and succinctly. They serve as a underlying basis for what you need to do. Don’t know how a specific module you’re writing is supposed to work?, look at the spec, it’s all there..hopefully.

There is nothing more annoying than doing work and have the spec changed/altered afterwords. Sure, this wouldn’t be the case in a agile development where the main objective is to go with the flow and change things as necessary in iterations. I have had the opportunity to work on an agile project and it was very pleasant. There is still organization within the project, but it’s just a little more fluid.

However, waterfall development is a different story. It needs to be approved and verified by a project manager, business and anyone else involved (VP’s, Marketing, Editors, Designers, Devs, etc). This type of development model is very simple once everything is in order. It never is. There is usually miscommunication somewhere, different expectations, whatever. Once shit starts rolling down the hill, it’s up to the developer to follow the spec and do the job. If everything is written down and organized in the proper way, development is a breeze. However, if one person has a different interpretation of what needs to be done, if someone fudged up on time estimates, or if the spec makes no sense to a developer, waterfall development fails; everyone depends on everyone else and one error can put a cramp in your style. Not cool.

So, what can you do to prevent it? Well, you can’t control the actions of the people around you, but you can control what is expected out of you. Here are some tips that I picked up along the way:

  • Confused?: If you don’t understand something, speak up immediately. It’s better to get it out of the way early than have the project delayed
  • Prototype: If you see a potential problem that can slow things down, but are still required, build a prototype. Isolate the problem and see if it can fit into the bigger picture
  • Estimate: If you are part of the requirement process, know your environment and make note of anything that would be time consuming or difficult (or impossible) to achieve.
  • Padding: If you think something will take x amount of time, add 20-25% more time to it. Trust me. It’s better to slightly over estimate than underestimate and have to work later than you’d like
  • Revisions: Prepare yourself for revisions. People love to be sure of what they want until they start to see it unfold, then it’s “move this here”, “add this here”, “let’s try this instead”. I wish this weren’t the case, but hey, people will be people after all
  • Time is money, don’t waste it