Stay focused and keep shipping.

Two hackathons coming up these days.

Can’t. Wait.

Books I’m reading right now..

I like reading things that are not strictly related to computer science. I’m reading the following books right now and highly recommend them.

Developer Productivity Report 2012 (Java tools, tech, devs and data)

30 pages of stats, analysis and interviews with industry experts on technologies and tools used by Java development teams. Great read! [Get it here]

Credits: http://zeroturnaround.com/

Things every software engineer should know #3

Understand the business of the customer.

If you don’t know the what and why, it’s hard to figure out the how.

On Time Management (by Anthony Finkelstein)

Great tips on time management from Professor Anthony Finkelstein. (BTW, his blog is awesome and has a lot of great stuff: http://prof.so/)

The very idea that I should attempt to write about time management will doubtless evoke a certain amount of hilarity among family, friends and colleagues. Perhaps however, because it does not come naturally and because I am constantly fighting the good fight to gain control of my time, my reflections might be of value to hard pressed scientists and engineers. I can certainly say what has worked for me and what has not worked, or more accurately what I have not been successful in implementing, which amounts to much the same thing.
I have read the books and even taken a course. In each case the amount I learnt was limited, there was a vast quantity of general ‘guff’ for every nugget of useable guidance. That being said, what is useful may to a certain extent be personal and I have probably filtered out material that would be of value to people with different work patterns and personalities. Please read what follows with that in mind. The best advice has come from mentors and people who know me well. Frankly, I am grateful for any assistance.

Do the important things rather than simply the urgent ones. The first rule of time management and almost certainly the most difficult to adhere to. Pretty obviously the urgent things are URGENT and we all, I assume, want to minimise embarrassment and avoid exposure of our inefficiency. The best advice on this matter was dispensed by a London cab driver, we were discussing the difficulties of driving in London: ‘I stopped stressing out, mate, when I realised it was the guy in the back who was in a hurry’. So, precisely, urgent for whom, urgent for you or urgent for them? If urgent for them, for a good reason or not? The important stuff is usually the longer-term, transformational projects, things that make the difference. Prioritising trivia is not going to take you where you want to go.

Triage incoming work. This is basically ‘classic’ time management with a bit of GTD (Getting Things Done) thrown in. Quite a few items fall in the ‘only touch once’ category: read and respond as rapidly as possible. Other items are ‘one-offs’ that might take perhaps 15-30 minutes of work: set them aside and handle them in a timetabled ‘review period’ (perhaps at the end of each day), try and clear this list weekly, setting aside time for this clear up. Big tasks should be identified as projects: break these down into a list of immediate actions, chip away at them on a regular basis, move the projects on action by action, keep the projects live by identifying new actions. Keep action and to-do lists in a good software tool. Record actions and commitments even minor ones. It is very easy in a meeting to agree to an action, if you do not record it it will either be forgotten or, worse, join the mental backlog, drifting in and out of consciousness and contributing to worry and stress.

At some points in time there will be more to do than can be humanly accomplished. In this case ruthlessly drop stuff on the floor. There, you will not hear a time management guru tell you that. Sometimes you have to say ‘enough’ and put some work out of sight and mind. Forget it and move on. Quite often ‘good enough’ is just that – good enough. This goes particularly for decision making. A sub-optimal course of action taken quickly and decisively is usually much better than the ‘best’ decision based on a complete analysis but infinitely delayed. Again, the time management principle here is ‘keep rolling’.

On occasion work items will fall into a psychological ‘black hole’. Relatively minor work items are endlessly put off or consigned to the bottom of the list. You have to confront this behaviour and acknowledge to yourself the reasons for it. Usually once the crunch point has been reached the task will prove relatively painless to accomplish and the mental anguish will have proved unnecessary. Despite this you owe it to yourself to reflect on the experience and understand how it can be avoided in the future.

Many days contain potentially ‘dead’ time. Time spent in transit, waiting, or otherwise in limbo. Much of this time can be scavenged and put to productive use. Reading, making calls, emailing and so on. Often the best use of such time is however, thinking. This actually requires a conscious effort in order to turn ones mind to a problem, stare blankly into mid-air and let an idea take wing. Strangely, thinking time rarely features in the time management canon but is the seed of creativity.

If the seed of creativity is time to think, then the subsequent growth of creative ideas is the product of ‘connected time’. That is the time needed for sustained intellectual work and, overworking a metaphor, to ground the ideas that took flight above. You will need some of this connected time and it will need to be prised out of a busy schedule. My experience suggests that the greatest enemy here is yourself. The temptation to engage with trivia as a displacement activity can be overwhelming and the misleading sense that you are somehow engaged productively is particularly dangerous. Here there is nothing to be done, no shortcuts, and no strategy except determination.

It is important to know your unproductive time. I am least effective in mid-afternoon and most effective at the beginning of the day, I can do good quality concentrated work in the evenings up to about 11pm after which my effectiveness diminishes drastically. I now know this and, though I struggle to achieve it, I prefer to use my best times for the sort of work that most benefits from the use of that time. Less important work can be assigned to lesser quality time.

Get a good PA and hand over control of your diary. Let them manage your office, travel and day to day organisational tasks. I realise that this advice is not accessible to everybody but using whatever office and personal support is available to the maximum extent possible is a highly effective strategy. Many people make ineffective use of such personal support because they are unprepared to invest the time necessary to get the most from it. Learn from your PA, they will have the experience and, critically, the objectivity to assist you.

On the journey home each evening remind yourself of what you did, not what you did not do. This is the most important psychological requirement for ensuring that you manage time rather than time managing you.

Do not read blogs and above all do not write them.

An object that moves by folding and unfolding itself

I think this is pretty neat.

Things every software engineer should know #2

Standard data structures, algorithms and Big-O-Notation.

Move fast and break things.

I’ve been working like crazy in the past couple of months and this has been one of my mantras.

Facebook's motto

Good stuff coming out soon. ;)

Things every software engineer should know #1

“Adding manpower to a late software project makes it later.” ~ Fred Brooks

Looking forward to Google I/O 2012…

…and it’s always good to watch some of the previous Google I/O talks again and refresh the mind about some important things.

WebSockets in Tomcat 7!! (FINALLY!)

With the 7.0.27 release the Apache Tomcat team introduced a WebSocket implementation (WOOHOO!).

Long story short, WebSocket is considered the next step in evolution of web communication and offers event driven and bi-directional communication over HTTP.  Major servlet containers are publishing non-standard APIs for now and whether that will evolve into a full WebSocket API remains to be seen.

I don’t know how it took me 20 days to realize this has been released, but the weekend is approaching fast. Let the hacking begin!

:-)

How to succeed at anything

Great visual advice from +Buster Benson (http://bustr.me) on how to succeed at anything!

Three tips to succeed as a programmer by Goranka Bjedov

Good article that Goranka Bjedov published on behalf of the Facebook Engineering team on their facebook page last Tuesday.

I’ve learned a lot of things over the years that I wish I knew before I graduated. From choosing the right job to figuring out where to focus in programming, here are three simple tips I’ve learned to help you as you embark on your career in software engineering.

1. Look for jobs that will let you program.  

You didn’t spend the past four years studying this field to stop now, right? You want your job title to be ‘software developer,’ ‘software engineer,’ ‘programmer,’ ‘coder’ or whatever other name describes exactly what you want to do.  So, make sure to steer clear of positions in marketing, testing, sales, etc. and seek out companies that are interested in hiring and mentoring you along your chosen career path.

2. Don’t give up on becoming a programmer.

Your education is only just about to begin.  After spending years obtaining a degree, brace yourself because the amount of time you’ll spend working on collaborative projects is where the real fun kicks in.  So far, you’ve probably been writing code, and that’s good. But to be a programmer, you need to learn how to readcode. That’s the hard part because it requires you to understand, maintain, fix, and extend existing products.  You will have to become very good at reading code and deciphering what other programmers intended to do.

This will be frustrating and hard. You’ll feel like you’re not good at it, like the job is too difficult, like you could do so much better if you only rewrote everything from scratch. But it’s not too hard, and with practice, you will get better, and you will understand. Expect it to take time, and know that the rewards are certainly worth it – good programmers can change the world.

 3. Learn how to take charge of your career.

Spend some time to figure out if you want to work on front-end code, back-end code, new product, or something else. Ideally, you’ll get to move around and learn from each unique position. So, if there’s some new and interesting opportunity to move, raise your hand and find your spark. People are not likely to come searching for you when great opportunities show up because there are probably going to be plenty of other people to choose from.

This can be hard, but you need to get out of the mindset that you are being pushy, demanding or somehow greedy when you do this. I’m not saying you need to trample over everyone around you and fight to the death, nor am I saying that you should demand to be given a new task. What I am recommending is that you find a way to politely indicate your interest and excitement about the opportunity to the right people- your boss, whoever is in charge of the opportunity, possibly the lead developer, etc. Find out how you could be a part of it and make the transition. The worst-case scenario is that you are told you are not quite ready; in which case you can work on figuring out what else is needed and be ready for the next opportunity that comes up.

Part of managing your career means taking a stock of your personal progress once or twice a year, especially early on in your career. Are you achieving your goals? Are you getting more complex tasks? Is your work increasing in scope and importance? If you notice yourself stagnating, take action right away. You don’t want to find yourself five years after starting your job still at the same level as a college new grad.

So, remember: learn how to read code, dedicate yourself to programming and manage your career.  Soon, you’ll be up and running in the programming world and making an impact.

Goranka Bjedov is a capacity engineer on the Tech Ops team at Facebook. Goranka recently shared some of this advice at a computer science event with women from Mills College in Oakland, Calif.

I completely agree with the learn how to read code part. More often than not, that’s what you’re gonna find yourself doing, and as with natural languages, the better you read, the better you write :).

Hello world.