Email overload

Ask anyone that has been online with the same email address for more than a few years and you’ll rarely hear them say that they have no issue with spam.

The truth is that as soon you start to use an email address for anything like everyday use, you will start to accumulate spam and other unwanted messages.

Email itself is kinda broken this way. The costs of sending are that small that it profits people to send out millions of untargeted emails in the hope that they get a response from that fraction of a percent that might bother to read it.

There have been a number of attempts to redress this balance but none of them have caught on outside of a tiny audience.

Personally I gave up trying to fight it head on. I use a lot of spam filtering and manual white and blacklisting which makes email usable for me, but for everyday use I use instant messaging to communicate with collegues, email only being used for big messages or forwards from other people – and I like it this way.

If something is urgent, then email is useless, the feedback loop is too open. It needs to be something more immediate in response. IM works here and for when it doesn’t work for one reason or another, I use Textsecure a secure SMS replacement app for android.

This isn’t perfect, but it is working for me so far.

Bi-phasic sleeping

Now that I don’t have to get up for work at a fixed time, my body seems to be heading towards a biphasic state; which I am told is natural for humans and what our ancestors did.

Typically this means that I go bed about 10 or 11pm and sleep for a few hours; typically 1.5-3 hours correlating to 1-2 REM cycles. Get up and work for a few hours and then head back bed for another REM cycle or sometimes 2 if I am really tired. This means I am naturally getting 4.5-6 hours sleep a night and not feeling particularly tired at the end of it.

I have to admit, this is a nice state to be in some respects, but it isn’t helpful in others as I am out of sync with my girlfriend who is on a fixed schedule with regards to uni.

Moving on

After tomorrow I wont be an employee of Synety anymore.

In some respects this is a good thing; I wasn’t in a good place head-wise, but I will miss the place.

I am thankful for my time there, I have learnt a lot about myself and faced many challenges I hadn’t faced before in my career.

I might not have agreed with every decision that was made, who does, but I liked the company. I liked the people I worked with, and I enjoyed most of the work. I just needed a change; a break from the stress.

Synety itself is fast paced. It has needed to be to grow as fast as they have, but that speed of change takes it toll. While I could have coped with it had I not had other stresses in my life at the time, for me it was just too much.

You don’t realise it at the time, but stress changes you. It upsets your health. It upsets your relationships with friends and family and left unchecked it will change you as a person.

I wish them well in their future business dealings, but for me it is on to pastures new.

 

 

Gravatar

I recently implemented gravatar on a site for a friend and he was worried about the security of the 3rd party service.

I told him at the time the biggest issues are likely to be confirmation attacks and leakage attacks.

Fast forward to today and it I happen across this post.

What it comes down to is that a lot of the display names people use on a site are similar to the user part they use on their email addresses. Combine this with the ability to check the top providers (gmail/yahoo/hotmail etc) easily and you can typically confirm that an email address is genuine or not using offline methods by comparing the hash in the page to the hash from the calculated hashes for the username and provider.

I’m not sure that there is an easy solution here.

You could ask the user to add a new email address for the site and associate the picture with it. You’d only leak the site email then, but this is extra overhead for the user.

You could ask the user to upload their own image to the site and opt-out of gravatar, but both of these negate one of the reasons of using it in the first place – to reduce user effort.

Much that I dislike the data-creep of big corps like facebook, google or twitter, I think they all have it right in that you use a site specific id that is unrelated to your email. This mostly prevents external leakage, but you are still leaking a lot of information to the identity provider.

Learnings part 4

9) Business decisions should not be taken personally.

Getting fired always hurts one way or another. It hurts you – you wont be getting paid for that job any more. It hurts your boss – It isn’t pleasant knowing you are putting someone in that position and it hurts your colleagues.

However, do not to take it personally. The decision should have been made for the good of the company and the company is more important than just a single person (if it isn’t then you have other issues, but we wont dive into that here). Being able to maintain a healthy working environment, with work getting completed and money brought in is the primary need and anything that affects that balance needs to be dealt with even if it does put you in a bad position.

Perhaps it isn’t getting fired, perhaps a change in hours or on call pattern, but whatever they ask you can always say no – you don’t need to suffer in a job.

We live in a world of increased job mobility and it isn’t likely to improve any time soon.

10) Never shit on your peers.

Out of all the start-ups I have worked with/for, the most successful ones were the start-ups with founders/management that weren’t trying to play games to squeeze every little bit of work out of their staff. Get some good will and the staff will do miracles when needed; screw them and they will just do their hours and leave it at that.

The same goes for colleagues. Screw them around too much and they will only do things for you that doesn’t disadvantage them at all.

Learnings part 3

6) You don’t need to suffer in a job

It has taken me a long time to realise it, but the most important things in life are not how much money you bring home or how many hours you spend at work. You wont be lying on your deathbed thinking “I wish I had spent more time at work”.

What is important to you will vary person to person, but I would guess it is likely to be one or more of the following: family, friends, physical health, mental health or perhaps even certain good causes.

As someone who has both been hurt in a car accident and burnt-out and come back, this has been a hard learning experience, but something I do believe.

7) Don’t be afraid of change. Change is where learning happens.

If you do the same tasks the same way every day for 10 years you are unlikely to learn much. To learn you need to be exposed to new ideas and change.

The one thing stops us changing things, and by extension learning, is fear. Fear of the unknown and fear of breaking things. We can solve both of these to some extent by culture.

Pairing up can reduce the fear of the unknown, you have someone else to reassure and provide support when you need it.

Fear of breaking things is harder, but not impossible. Understanding that failures happen no matter what, having processes to deal with failures and not dealing out blame during or after the event all go some way towards making changes less fearful.

8) Don’t be too quick to change something that is working until you understand why it works.

We all understand that change is necessary in business; the outside world isn’t standing still and we need to adapt to these changes. Changing things therefore is an everyday task; a task we need to retain our market fit and to improve the business.

The problem is that if we are too accepting of change that we will continue changing stuff when it doesn’t need it and when doing so will be a detriment to the business.

I have seen this is many places; people that need to change something to feel they have made some input into a problem, people that like to shake things up a little, or even people who like to make others uncomfortable because they can.

The one thing all these have in common is that these are changes without a good reason or a plan. There is no testing and no rationale as to why this is going to be a benefit; it is just a change for change-sake.

 

Learnings part 2

This post will be a little shorter than the previous one, but I hope you still find some value in it.

3) People will be nice when they perceive things going their way.

Everyone loves good news. It lifts mood and makes them far more hopeful about the future. They tend to also be easier to get along with and more generous in time and money or other resources.

This includes you!

4) Things wont always go your way.

While the old adage ‘make hay while the sun shines’ still holds true. You should also be prepared for times when things aren’t going your way. Hold back some cash. Have a plan B (and plan Z) and just generally keep options open.

5) Great people will help you reach goals even when things aren’t going their way.

The most successful people I have ever met are not the people willing to stab someone in the back to get ahead; it is the type of person who sees you fall and goes out of their way to make sure you are okay.

This produces a lot of goodwill and it tends to come back to them many times. People remember the kind word when they are low and the helping hand when they are on the ground.

Sure, there will be people who try to take advantage of this, but they will be in the minority.

Is coding art?

I was recently asked this question and after lengthy contemplation I have to argue that as most people practice it no, it is not art.

I am not trying to take away from the great works of these people. Far from it. Being ‘art’ is just a label. It doesn’t make it better or worse than anything else.

So why am I stating that most code is not art? It comes down to a few reasons:

  • The act of writing source code is creative, but it is not the finished work.
  • The finished work for most languges (except for raw machine code and some interpreted languages) is not the work of the coder but actually the result of the compiler, the coder generally can’t predict what exact form the output from the input will be, only the function.
  • The only form we can really judge the creator on is the user interface (and perhaps the resource requirements (64k code competitions for example)), but this is very different from putting pigment on canvas or other similar processes we easily define as ‘art’.
  • If we are only able to judge the creators code on the function and not the form, then it isn’t art. It is creative but not art as such.

This last points I think is the important ones. Building architecture is a hybrid of art (form) and engineering (function) and I think we should look at programming from a similar perspective.

Modern architecture uses a lot of computer assistance to design a building; from calculating loads and resource requirements to in some cases designing the actual form of the building itself with only minor tweaks from the architect. This is a very wide range and we accept that (although arguments still exist both ways).

So can programming be art? I think so, especially where the source code itself is the output. Take ‘Obfuscated Perl’ contents as an example. The code is the thing to be admired, the function merely a selection criteria. The ‘Brain fuck’ language is a little less clear cut as the language is still compiled, but the only real use is the challenge of writing or understanding the code. I suppose in this context it could be looked at as performance art, except that generally you are performing alone.

Logitech G510 Keyboard (GB) under Wheezy

My previous keyboard (a cheap and nasty replacement for an IBM Model M) started to die recently.

It wasn’t a massive failure, just some keys not registering first time – not useful when coding where accuracy is important.

So after looking through the options and talking to friends I realised that a great keyboard would set me back well over £100. So I looked for cheaper alternatives.

A friend suggested looking at gaming keyboards. There are a lot of cheap gaming keyboards on the market and most of them are complete crap. One name that has been around for a while and does have some good reviews is Logitech.

After considering the options I settled on a G510 (as there were some cheaper and pristine 2nd hand models on ebay going cheap).

20141009_162129

There wasn’t so much of an unboxing as an opening of the reasonably well-packed jiffy bag.

I liked what I saw. So I swapped it out with my old keyboard on my Debian Wheezy workstation.

Suprisingly it worked. Out of the box the media keys and normal keys worked absolutely fine. The display was fixed at g510 in blue and a blue backlight on the keys, but it was a good start. I could live with this level of function worst case.

I initially tried installing the g15daemon and apps. After solving the /dev/input/uinput issue in the initscript and getting a version of the library that supported the g510 we looked like we were getting somewhere. I hit a few stumbling blocks and tried the alternative option…

The Gnome15 project is suprisingly well polished. After adding the repo and installing their gnome-suite-fallback metapackage and rebooting (logout alone didn’t seem to get me all the way there) I had a fully working keyboard. I was suprised; happy but very suprised.

The notification area control app doesn’t have many functions, but it has enough to make it very useful.

Screenshot from 2014-10-09 17:52:40

The first tab controlled the backlight and whether the display cycles between the various enabled plugins.

Screenshot from 2014-10-09 17:52:43

The second controls the various macros (my media profile inherits the macros from the default profile and so has none of its own)

Screenshot from 2014-10-09 17:52:46

…and the third controls which plugins are enabled.

The way I am using it is to have a default profile that only enables a couple of plugins (primarily the pommodoro plugin for coding) and a second profile that I have with my media player displaying on the screen. This seems to work well enough for me to start with.

Overall I am happy with the keyboard. The build quality is good and the key-response while a little spongy is usable. I would certainly be tempted to go up the range a little to get something with better switches as funds allow.

Edited to add:

Low light use

Not massively bright, but certainly enough to code or game by. The monitors kick out a lot of light, but in a terminal session where the screen is mostly black, the backlight is certainly bright enough if you do need to look at the keyboard (like when I am one key out from the home positition).

20141009_183109 20141009_183418

 

Learnings

A few months ago I posted a list on twitter about 10 things I have learnt in my career; things that I wish I’d have known at the start of my career.

In the next few posts I will expand on these points.

1) Short term fixes will 90% of the time become long term production processes.

Much as we like to believe that a quick fix will be just that; that we will come back to it when we have time and fix it properly, it is rare we will ever find the time to do so.

This isn’t about intentions or anything else. It simply comes down to two facts:

  • This problem isn’t an irritating enough ‘itch’ any more and so you aren’t compelled to scratch it.
  • Once it is in production it becomes business critical and it becomes far harder to do anything to change it.

This ends up being an excellent argument to fix it right the first time. Alas, in this business driven environment it is hard to commit the resources to doing it right when ‘good enough’ will fit the business need.

2) You will never have full requirements, if you do they are out of date.

TL;DR version: Agile and similar iterative processes are the right way to do things. Business and technology changes too quickly.

When I learnt about Computer Science in the early 90s there was no agile. Waterfall was the normal method taught and people used it – and projects failed.

Not all projects; that would just be silly and not a total failure. Just enough failure to mean that projects didn’t fit the changing business needs particularly well.

With the advent of drag and drop UI builders and languages like VB (much that I hate the language) apps were quicker to develop and fairly consistant in their UI.

Extreme programming and agile was an extension to this. They didn’t have all the answers but they changed the model from upfront design to incremental improvement. You could put a mostly working app in front of a user in a few hours and the user could start to understand what you were describing.

This accelerated the pace of the IT industry. We now see an MVP as an integral part of most startup’s business plan and the only people left doing waterfall or similar development methods are mission critical application developers (flight systems for aircraft and spacecraft, process controllers etc.) and government contractors who are lagging behind the times by about 20 years – although it is nice to see this is changing.

2a) Design with change in mind

This wasn’t in the original set, but I think it is important.

If you design and build tightly coupled systems then sure, you will get maximum performance out of the system. The problem is that changes to the system become difficult; changes to part of the system end up requiring changes elsewhere as the interfaces and data structures change.

With this in mind I tend to recommend loose-coupling using well defined interfaces now. Using interfaces like REST or Message Buses and interchange formats such as JSON (and XML if you really must) you can avoid the need to make changes in multiple places as business requirements change.