Life as Code

refactoring my life

Archive for the ‘productivity’ Category

a little product management

leave a comment »

Even if you’re just a developer, a little product management will open your eyes.

I know, you think it’s all about marketing, and it is, sort of, but from time to time an article series like Practical Rules for Product Management makes it fun, even for non marketers. So, enjoy:

Written by Bogdan

February 13, 2013 at 10:48 PM

it’s not that important

with 2 comments

Moving slow lets you finish faster.
Asynchronous communication doesn’t make you less productive, it makes you more productive.
Meetings for the sake of meeting are just poison. They just take everybody out of their flow.

If people tell you that it’s important, it’s critical, it can’t wait, it’s high priority, take it with a grain of salt.
Few things in life are important or critical, people make them appear that way.

Written by Bogdan

February 7, 2013 at 5:38 PM

Inbox zero heresy

with one comment

Lately I’ve seen a lot of people posting and tweeting, bragging about how zero their inbox is. This is funny and sad at the same time.

envelopes

It’s funny because they’re getting it wrong… it’s never about having an empty inbox. It’s sad because at the end of the day they have an empty inbox but they didn’t get anything done… they were too busy getting their inbox to zero :)

Maybe the name ruins it all.

Maybe people get it as “I should spend as much time as possible checking my email, cleaning it, moving it to folders or deleting it so I can get it out of my mind, because that has some sort of psychological effect, relieving me of my pains and stress”, taking it from an ongoing habit to permanent effort.

It’s ironic that something meant to help sort things out and liberate more time for creative and productive work… actually transforms into a time-consuming and stressful (“not at inbox zero yet… have to get there… omg”) activity.

Think about this: If you’re checking your email every 5 minutes, you’re checking for new email 24.000 times per year.  

What’s worse is that it turns into some sort of procrastination aid.

It feels like productive work, because you are clearing stuff out. Right? You are advancing and getting somewhere.  Right?

Well, no. Inbox zero isn’t somewhere.

Don’t set your goal to have inbox zero… set your goal to actually get more things done right, both in quantity and quality and you’ll get somewhere.

Written by Bogdan

January 2, 2013 at 4:41 PM

addendum: learn to answer later

leave a comment »

I refuse to answer that question on the grounds that I don’t know the answer.

- Douglas Adams

When asking somebody a question, assuming that they are even listening, you can expect them to either:

  • know the answer
  • don’t know what you’re talking about

If they know the answer they’re going to give it to you right away, and that’s fine… because they know what they’re talking about.

If they’re in the clueless gang, they’re either going to give you a “sort of correct in their own opinion” answer or they’re going to recognize the fact that they don’t know, honestly. I just hate it when people give me “their correct answer”… and I’m not the only one.

Most people don’t realize that the choice they make in that exact instance is a make it or break it deal, especially if it’s a first impression.

Appearances do matter, and somebody jumping directly to conclusions even if their knowledge of the situation or problem at hand is close to nothing will automatically get tagged as either “clueless” or just plain stupid.

On the other hand, being thorough and wanting to give the correct answer (not the first one) is highly prized, because… it’s more productive to work on facts rather than fantasy.

So, if somebody asks you a question that you should be able to answer but you can’t:

  • honestly say that you can’t answer at this time and that you’ll get back to them in a very short time
  • find the right answer and validate it – if you’re going to take your time, make sure that you are right
  • get back to them as quickly as possible - never over-promise and under-deliver

This is really important for anything related to costs (such as licensing issues and estimates), compatibility or interoperability questions (most of them are tricky anyway) and client-facing issue.

Ensuring that your answers are correct and that you had time to think things through will help you do your job better and I’ve never seen a manager say “I don’t want the right answer in 10 minutes, I want the wrong one now!”.

So don’t just get things done, start getting things right.

Written by Bogdan

October 23, 2012 at 11:30 PM

Learn to say no, your work deserves it

leave a comment »

I know it’s really difficult to say no and that you just accept things because of your inner fear of conflict and lost opportunities. You just have to get over it and just learn once and for all how to say no! You’ll do yourself a favor… and everybody else.

The next time your boss (or anybody) is trying to push down an extra task on you just say “I’m sorry but I can’t do this right now.” in a straight and non-defensive manner. In time, learning how to say no will let you focus on the tasks at hand and it will change the habits of the people you work with – they’ll be more picky about the tasks they delegate to you.

If they ask for an explanation just say the truth – that your schedule is already full and that another task will just lower the quality of your work along with actually delaying your already existing tasks.

If they don’t understand “loss of quality” and “delay”… well, it’s their problem.

Quality is a rare commodity these days and we have to fight for it, even if it may hurt some feelings or even if it pisses some people off. In the end, quality always wins.

Written by Bogdan

October 15, 2012 at 10:31 PM

Replacing images and icons with CSS3 web fonts

with 2 comments

It’s really hard to create beautiful and clean web interfaces when you have to slice and dice images for every little button, action or highlight. Well, now you can replace them with web-font characters styled with CSS3 – as most browsers have support for them.

Here’s a sample from something I’m working on just to give you a feel:

Image

Wait, there’s more: using styled glyphs instead of images gives you more flexibility with application themes – and less images to mess with:

Image

The nice thing? What you’re actually seeing above is :

<div id="header-toolbox">
     <a href="">c</a> 
     <a href="">U</a> 
     <a href="">S</a>
     <a href="">X</a> 
 </div>

It’s actually dynamically built with JavaScript but you get the idea.

The font that I’m using for the glyphs is Web Symbols, available from http://www.justbenicestudio.com/studio/websymbols/

Written by Bogdan

September 29, 2012 at 3:16 PM

A project objectives checklist

leave a comment »

Objectives help your team to focus on the tasks at hand while not losing sight of the overall outcome that it needs to reach.

A good team is results-oriented, focusing on what it is trying to achieve not what it’s currently doing.

Use this checklist to verify that the objectives defined for your project will help you achieve results and won’t hinder your efforts.

  1. Are the defined objectives clear enough?

    Contrary to goals, objectives must be focused and clear. Understandable objectives will drive the team to successful results.

  2. Are the defined objectives SMART?

    Do the objectives comply with the SMART criteria:

    • Specific
    • Measurable
    • Achievable
    • Relevant
    • Time constrained
  3. Is the number of objectives right (4-6 range)?

    There is no right number of project objectives but taking into account the fact that objectives should be known and tracked by the team, a low number (having between 4 and 6 objectives is a good compromise) will make it easier for the team to keep focused on the essential. Remember, the more objectives you have, the harder it will be for your team to keep track of them.

  4. Is there a known and clear context?

    The defined objectives must be linked to the overall context. Objectives that do not advance the project (useless objectives) or that are contrary to company strategy (like building a whole new product that competes with one that already exists) should be eliminated or changed. For each objective yourself these questions:

    • Will achieving this objective advance the project?
    • Does this objective tie in to the project and company goals?
    • Does this objective follow the company strategy?
  5. Are the defined objectives known and agreed upon?

    It is important that all stakeholders know and agree to the defined objectives. It is very important for project success that the objectives are known and agreed upon by project sponsors and executives.

  6. Can each defined objective be tied to a deliverable?

    Think of this as a post-SMART check. If you can pinpoint at least one deliverable that helps you attain an objective you are OK. If you can’t ask yourself this: how are we achieving this objective? If it doesn’t matter, you should remove it from the list.

  7. Does every defined objective have quality criteria specified?

    Besides being measurable, each objective should have quality criteria defined, so that both quantitative (are we there yet?) and qualitative (is it the right thing?) parameters can be tracked and accounted for. Getting it right is just as important as getting it done.

Written by Bogdan

September 17, 2012 at 12:54 AM

Apis – The Web API builder

with one comment

 

I KEEP six honest serving-men

(They taught me all I knew);

Their names are What and Why and When

And How and Where and Who.

Rudyard Kipling

 

What?

In Prototyping the web API I started describing an idea to build a tool that can be used to try out/prototype web APIs before actually building a back-end implementation, helping a team to describe a clear and strict HTTP API, as well as allowing them to build and test client code without having written one line of server-side code.

This post is taking those ideas further, trying to crystallize the concept, objectives, goals and my overall expectations of this tool.

Based on my previous attempts at crudely building a harness for my web development habits, I’ve outlined a sort of a wishlist.

Apis, as I’ve so naively chosen to name this tool will be a part of my typical development stack and must:

  • Have a pleasant, easy to use interface where I can define the desired HTTP API, including endpoints, request and response configuration that I can export as a well-structured definition document;
  • Allow me to save the definition in a human readable and human editable format that can also be saved, compared and merged in a VCS;
  • Allow me to define standard responses for each API endpoint based on the request configuration so I can test the API, build a proof-of-concept API and even build a whole user interface decoupled from back-end services;
  • Allow me to define static resources that will be served alongside the standard responses, such as JavaScript frameworks, CSS styling and any other kind of resource I want to serve;
  • Be standalone and packaged in an easy-to-use installer so I can send it to my fellow developers that can load the API definition from VCS and work on it.

That’s about it. If it seems pretty simple, it’s because most useful things are, and should be…. simple.

Why?

This is a simple one:

  • I like a well-defined, clear and strict web API in my projects. I want others to want one too;
  • I like to prototype a lot. I want to be able to quickly prototype a web interface without having to set up a web server or -hell no- a full development environment. I want to make it easier for others to prototype;
  • I want to test my decoupled web clients in a clean, well-known state and I want my server-side code to have no idea who they’re talking to.

How?

This is a simple one too:

  • Not like I did before. I want a desktop app, not a whole bunch of code, glue and configuration files;
  • I want to build it clean, so I can easily extend it. I don’t really care about other operating systems than Windows so I’ll build a Windows desktop app;
  • No bloody way I am building it in some scripting language again and I code Java professionally so I don’t want to do it in my spare time. Plus, I really like C#, the .Net stack and WPF;
  • I’ll build it in my own time, build it right, and build it for myself (for a change).

So, Windows, C#, WPF, VS Express and a whole lot of will power it is!

I’ll build it iteratively and story-based. I won’t say agile because well, for an agile process treating communication and people problems… let’s say that you need a minimum of two people for hate or love.

When, Where and Who?

There’s no better time than now and no better place than wherever I am. The Buddhists say it well “Wherever I am, I am home, I am now, I am free”.

I’ll start building it alone. I know it’s not a good idea to work alone, that in programming, one is the loneliest number but later on, if it catches on, I’ll try to get some other people on board.

I’ll host everything on gp… it’s been lonely since the migration to WordPress.

That’s it for now. I was storing this in my brain, which is stupid… that’s why I have a blog.

 

Written by Bogdan

September 14, 2012 at 8:15 PM

Schneider’s Culture or How we do things work around here to succeed

leave a comment »

 

Written by Bogdan

May 22, 2012 at 9:27 AM

Writing it down is good, doing it is better

with 2 comments

Either you run the day or the day runs you.

Jim Rohn

I always try to sell the “write down everything that you need to do” mantra to everybody.

It’s not just because it works for me, it’s because it works for everybody I ever worked with, everybody I asked and just about every productivity book I ever read mentioned it.

The mantra is very simple:

  • I use a piece of paper (usually a page in my notebook – paper notebook smart-ass) to create a list of things TODO
  • If I get a new task, I write it down
  • If during my work I realize that there is something else that I must do to accomplish the task, I write it down
  • If during my work I think about something that must be done later on and hope that I don’t forget, I write it down
  • When I do it, I scratch it off the list as being – you guessed it – DONE

You might be thinking “this douche is trying to sell us the TODO list crap” – and you’re right, that’s what I’m doing.

You would be amazed at the number of people who are actually trying to remember (with their actual meaty mushy forgetful minds ) the things that they need to do during an entire day – even an entire week, so the list thing… well, let’s say that it needs a good refresh from time to time.

You would also be amazed at how much a piece of paper and a pen used – religiously – as a TODO list and actually followed on a daily basis could increase your productivity. You should try it. Screw Outlook reminders and other RememberTheMilk simulacrum – try using a real piece of paper and a pen, and really scratch the hell out of a task when you’re done. You’ll feel a lot better.

Although this seems to be the direct that this post is heading, it’s not about using TODO lists, nor even about prioritizing them (although it would be a good subject) – it’s more about knowing when not to use them.

Let’s say that you’ve been using TODO lists for a while now. It’s really working for you. You’re burning two A4 sheets a day with your tasks, passing the unfinished tasks on a new list each morning. Handling it, feeling the DONE thrill every time you scratch something off.

Then you start to notice something. Some really simple, really small tasks seem to remain on your list for more than one day, maybe two, maybe even a week. And when you finally get to them you realize that those tasks were under 10 minute tasks. Some of them were even important, or could have brought a benefit, or even a favor. So this is what this post is about.

It happened to me awhile ago (a couple of years to be exact – and yes, this is a revived draft, I tend to do this often lately) so I made this little habit of asking a few questions before writing it down:

Will it take more than 5 minutes?

If it will take more than 5 minutes – write it down. If it’s faster than that just do it – and save Mother Earth.

Are you doing something so important that if you deviate for 5 minutes it will be context switching?

If it will throw you off, write it down and do it later.

Can you do it in the middle of the current task, as a short mental break?

From time to time I need to clear my head of whatever nasty thing I’m working on and I found that (besides taking a walk around the office building) handling a short unrelated task clears my mind.

Can you delegate it?

If it can be delegated – write it down – and email it. Maybe have a quick chat about it.

Do you really need to do it? 

Think about this: maybe you don’t really have to do it. Is it really necessary?

I hope this helps you as much as it helps me.

Written by Bogdan

April 3, 2012 at 12:45 AM

Follow

Get every new post delivered to your Inbox.

Join 259 other followers