Christian Heilmann

You are currently browsing the archives for the annoyances category.

Archive for the ‘annoyances’ Category

Bad hiring practices in the valley (guest post on RWW)

Wednesday, January 19th, 2011

Some of you might recall the three reasons why large companies on the web are losing ground post and asked me to give more detail on some of the things that need fixing and how to do that.

I am proud to announce that ReadWriteWeb published a guest post by me called The Valley Lacks Flexibility, Not Talent. In it I discuss:

  • Outdated hiring practices
  • Local focus instead of acting like a global company
  • The myth of “Rockstar developers” as product saviours
  • Failed startup acquisitions
  • Interview practices that annoy applicants and give a bad first impression
  • Empowering your workforce to hire for you instead of replacing them

It felt very good writing all this down, hopefully it’ll be helpful for you, too.

view-source will teach you things that are wrong

Monday, August 23rd, 2010

Lately I find more and more people in comments fighting for the need for “view-source” in our web products and claiming it to be a “vital part of the open web” and a “great way of learning for new developers”. This ails me as it is in my point of view a very outdated idea of learning and building web sites. I am not saying that view-source is not important – I am saying that there are better ways of learning and analysing code.

When view-source was king

Back in the days when I started working on the web you learned by looking at the source code of other peoples live web sites, copying and pasting what they’ve done and reverse engineering the workings to see how you can use or improve it. This is how I learnt JavaScript as there were no free blogs, tutorials or articles out there to tell me. The books available (basically the JavaScript Reference) dealt with the technologies themselves and not their application in a browser world. JavaScript for example was still considered a toy language in comparison to the mighty Perl or ASP or PHP or Java.

A few years before the web I learnt Assembly Language by analysing games on my C64 and trying to get endless lives. I did this by freezing the game, checking the part of the screen that changed when I lost a life (the counter) and then hunting through the memory to find the code that altered the counter on the screen (finding the DEC). I learnt how to cheat the system – not how to write Assembly Language. That came later when I had spent a few years reverse engineering.

That kind of commitment we don’t have time for if you want to learn web development.

View source gives you a view and not the source

Despite the time spent, the problem with looking at a web site with view source is that you don’t see the source, but you see a view:

  • If you build web sites with performance in mind and in high end environments you send browser-optimized views to different browsers. This means that learners would see what is optimised for Firefox and then try it out in Safari. Or worse, they see what we need to jump through to make old IEs behave and consider this the best way of developing.
  • Live code is normally minified and concatenated and has comments removed. So you learn the how but not the why. Some of the things you see might be terrible hacks but necessary for the environment used to build the web site.
  • Checking generated source is even worse. Browsers add browser-specific code that the original writer never added.
  • Live web sites are normally built by committee and have a lot of things in them the developer feels dirty about: tracking codes, third party ads with ridiculous code quality, quick hacks to get the thing out the door at the agreed time and date.
  • Most web sites these days are not written by hand – if you build for the web and you don’t use the power templating, CMS and databases and web services offer you are missing out on a lot of great opportunities. HTML is the end product of a methodology and a build process – not the start of it.

Open source is the new view-source

If you really want to learn about how web sites are built and how to use certain technologies, look at the source code repositories instead. GitHub, SourceForge, Google Code and all the others are full of great examples. This is where developers communicate with each other and show off the newest technologies.

As the final product is created and not written by hand you will find the important comments as to why something is the way it is there.

Say my entry to the 10K competition World Info. If you look at the source code you will see minified JS and CSS, all of it inline. I would never code that way. This is the result of a build script. I tell the world that:

World info source code message by codepo8

If you look at the source on GitHub you get step by step comments how I have built the solution.

What would a new learner get more information from? This was not much more work for me – as I document where I write I keep things up-to-date. Even more interesting, I actually fixed a few problems and change my code while I was documenting it – as I was forced to look at it again from a different angle after having written it.

Learn the why not only the how

The main problem with teaching people how to become good web developers is that there is a massive lack of patience. Instead of realising that knowing the syntax of a language doesn’t make you a developer we think this is all that is needed. It is like learning the grammar of a language and then trying to communicate without having the vocabulary. Or analysing the syntax of a poem without looking at the metaphors and their meaning or the historical environment it was written in. Most of what makes development and writing art and craft is lost because of the lack of patience.

W3Schools is a great example. It tells you the quickest solution and gives you something to play with. This is why it is massively successful. It is a terrible resource though as it doesn’t explain what can go wrong, when this would be a bad solution and it gives people the idea that they know everything by knowing the syntax. The PHP documentation is better as you learn in the community comments how to apply the functions and how they fail.

If you really want to learn about web development and standards then there are a few very good resources:

And far too many personal blogs that I could list here now. None of these are 2 second lookup tasks – but once you went through some of them you will know the why and the how and you will be able to see what is sensible to take on from a source view and what is probably not that a good idea.

In praise of mistakes

Thursday, May 15th, 2008

I’ve been talking to a lot of developers lately in order to make people work better together and get things done faster. One thing that keeps fascinating me is the length people go to not to communicate mistakes and problems.

We are very much happy to celebrate successes and point out the obvious benefits of what we produce and do, but there is an innate tendency not to own up to mistakes or to welcome people telling you what is wrong.

I once heard the quote “a good friend tells you they like your shirt, a great friend tells you that you have dirt on your nose before you go on a date” (I think it was on Sherman’s Lagoon).

Mistakes are a great thing. They hurt, they make us think, they make us angry and they make us learn. The one wrong thing we do with them is to take these negative gut reactions and vent them in the wrong direction in most of the cases.

This is how we are wired, the first cave-man finding a burning branch after a lightning storm will have put his hand in the fire and quickly found out that it is a bad plan. He then most probably told others (the ones he liked) not to do that. He probably also pondered to use that fire against the ones he doesn’t like – sadly enough something we seem to excel at as humans.

Making mistakes makes us fell inadequate and uneasy – we failed as the crown of evolution and should be better than that. They also makes us feel protective – we don’t want to own up that we make mistakes as that would make us look weak or stupid in the eyes of others. This is a mistake in itself as we all are fallible and do stupid things all the time.

Case in point: I was chuffed when my first A List Apart article was posted – having been a fan of the site for ages. The article JavaScript image replacement sparked a very strong counter-post by Peter-Paul Koch, aptly named Why ALA’s ‘JavaScript Image Replacement’ Sucks.

I was shattered. PPK was someone I looked up to and his post accused me of stealing his idea and code (we solved that riddle on a mailing list proving with time stamps that I did indeed neither) and his critique was partly very right but in other parts just over-zealous.

I was hurt, I was confused and – well – pissed off. Instead of grumpingly packing in or shooting back I actually looked at my code and fixed the issues PPK talked about. I also started communicating more closely with him and this started a long, great discussion and sharing of information and contacts.

I grew a lot by my mistake, and there are no hard feelings between PPK and me – I will be one of the experts talking at the conference he organizes later this year.

In short – making a mistake, being called upon it and fixing it made me a much better developer. It humbled me and made me realize that working with others (even if it is only for a quick sanity check) makes me a lot more effective than I could ever be on my own.

This can be applied to products: instead of celebrating the successes, we should be celebrating issues that have been brought to our attention. A bug is a chance to analyze what lead to it to fix it.

This is the real opportunity – we have to learn not to do stupid things. Instead of huffing and puffing and – worst case – putting in a “stop gap solution” or a “quick fix” we should spend time to see where the bug came from, what lead to it, what impact it has and document the way to fixing it. There are millions of “best practice” tutorials and examples but not many “here’s how we fixed a nasty bug that caused this and that” articles.

The reason is guilt and fear of appearing weak and fallible. Well, I personally think that owing up to the fact that you do make mistakes actually makes you strong. The same way that appreciating good work of competitors makes you more believable than just banging on about what you do and act as if others don’t do great things, too.

I am quite sure that if we managed to turn the development culture around to see mistakes as a positive, we’ll make a massive step forward. A person pointing out an obvious flaw is not a whistle-blower and “not on message” but someone you have to thank for providing a chance to really improve our work and learn not to do things wrong the next time around.

Mistakes are OK - they do happen.

The joys and perils of working for a large corporation

Saturday, February 9th, 2008

This is not a technical post, but something that I’ve been pondering about for a while and it is related to a lot of comments and emails I get through here. I wanted to sum up some points what it is like to work for a large, very public corporation and what my points of view and my circle of influence are.
Lately I’ve been getting a lot of questions about this and instead of repeating myself over and over again, I take this as an opportunity to write a reference piece.

There comes a time in the career of a developer where you go up the hierarchy in your company. Most of the time this is because of your performance and dedication to the company but also to the wider market that you work in and due to the fact that you have proven to yourself that you are a good developer and team player.

Web Development is a very young profession and we do make all the mistakes that have been done in other professions before. One thing is for sure though: you need to keep your eyes open and roll with the changes of the market in order to succeed. If you take your job and the fact that the web is a new media really serious this means that you need to check out future technologies and ideas as much as delivering the current ones to full satisfaction.

If you’ve done this for several years and feel your forehead getting numb from running against walls trying to get this idea through to people whose main concern is to make enough money to be able to pay the wages and other company expenses you got two choices: start an own company, consult others or try to join one of the big players in the market.

The former two come with financial unknowns and a lot of stress. The second also comes with the decision to let go of some of your dedication as you cannot over-deliver. You consult, you invoice, you hope they get better and you leave for the next job. You know what to do right, but you hardly ever get the chance to really deliver it.

The latter – working for a future-facing, established corporation that is not in trouble – comes with a lot of positives:

  • You work for a company that has been around a while and knows how to treat employees so that they can deliver (this means HR issues are taken care of and the pay is no problem either)
  • You work for a company that already has a lot of developers working for it and doesn’t have to start understanding the value of good IT support. This includes getting adequate hardware, the right software and upgrades whenever they are necessary rather than when they fit the budget.
  • You get reach beyond your wildest dreams – millions of users – and learn about tricks of the trade you never thought necessary but that are when you want to deliver a great experience for all these people.
  • You get the chance to work with amazingly skilled people – those whose books you read and wondered how the hell they come up with great ideas like that.
  • You get to propose people you always wanted to work with to get hired – and find that there is a budget for that!
  • You find that there are departments in the company that research technologies and ideas that aren’t an immediate success but will be a great asset in the future. You even get kudos and maybe even more for proposing them some ideas.
  • You can learn from the massive experience of people that have been playing in this league for a long time.
  • You get company perks (free food, cheaper hardware, gym, health care and so on…)

All of this will make you happy but there is a flipside, too.

  • You are a geek, possibly even with a “scene” background and you “sell out to the man” in the eyes of a lot of people that saw you as an equal before.
  • People expect you to change drastically and you have to suffer many “tongue-in-cheek” comments about you “being assimilated”, “joining the mothership” and other “clever” remarks.
  • Whenever you talk about a product of your company, people will take it less serious than when you said the same prior joining the company. “Of course you say this is good, they pay you for it”.
  • You will be responsible for everything your company does, no matter how far removed from your area of expertise or even location it happens.
  • You will be judged not by the good stuff that happens but by the lower quality things the company produces – it is fun to poke the giant and show that you can do things better (whilst forgetting the dependencies the giant has to support that you don’t have to)
  • Naturally you will be considered to have insight into all the happenings in the company and probably can tell in detail whatever people might want to know.
  • It is expected that if somebody wants you to work for them (for example as a speaker at a conference) your company will gladly pay for your travel there and the accommodation and not the organization that wants you to work for them.
  • You are expected to be as rich as the richest director in the company, as all the goods are shared equally, right?
  • You will know what stocks to invest in as your company is big in Wall Street
  • You can get anyone a job in your company, even if they haven’t the faintest clue what they really want to do or what they can bring to the table.

Each of these is no biggie and you can shrug them off, but it is amazing how many of these happen day in and day out.

So here is what I do and know about my company and its future:

  • I work as a web architect, giving advice on frontend web development matters to the people who build the internal tools that we build our web sites with.
  • I am part of a team whose job it is to define the standards frontend web matters are delivered to.
  • I am working on internal tools to make it easier to re-use code and components across different products.
  • I propose people to hire and interview others for positions in web development
  • I am an external European arm of our development library and can offer information and talks about that
  • I am a speaker that can talk about all the public facing APIs, libraries and components we offer for outside developers
  • I am an internal trainer on all matters web development and human interaction (accessibility, writing for the web…)
  • I am reviewing internal code and products of Europe, Asia and sometimes the US
  • I talk a lot to teams in the US to make sure our standards tie in with their ideas and will become global standards
  • I talk to universities about hack days, challenges and other academic happenings.
  • I keep an eye on the team in Europe and around the globe to make sure that developers are happy and can do a good job – removing obstacles for them and talking people out of ideas that would mean a lot of work for the web developers without much gain.
  • I liaise with other people in the same positions and HR and PR to make sure we have some processes in place that will ensure that we can hire good people in the future and give potential new developers an insight into what it means to be a developer for a large site like ours.
  • I speak to the backend teams to ensure we work together smoothly and have methodologies that work hand-in-hand.

This is a lot, and it keeps me busy with the things I care about the most – cool technology that benefits web surfers and empowering people who want to build this technology.

In short, I talk a lot to developers, their managers and outside people about our technologies to make sure that we can deliver good products and have fun experimenting with new ideas.

And that is all that I know about in my company. Anything else, I’d venture to guess that you know more than I do!

Code tutorials for lazy people with Ajax Code Display

Monday, January 28th, 2008

Currently I am writing a lot of tutorials for an online self-training course about web standards and I ran into the annoyance of having to maintain example code in two places: the code itself and the HTML document with the explanations. Therefore I took jQuery and wrote a small script that automatically turns links to HTML code examples with HTML entities and line numbers. You can define which lines to display, which lines should be highlighted and you can add a live preview in an IFRAME when the link is clicked.