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!

One of the most annoying things to me on the web is new tutorials that are full of assumptions, bad practices and generally outdated. The irony is that when you tell the authors about the issues their excuse in a lot of cases is that the pieces are mainly targeted at beginners.

How does that make sense? Surely when you want to cater something for beginners nowadays you’d want to make it work for them today, and not base it on old technology and practices.

Catered for the audience

Back when I still had a television there was one public service ad in Germany I really liked: it was a man talking in baby talk and acting terribly silly. He then bowed down below the camera, you heard a slapping sound and he re-emerged with sticky tape over his mouth. The announcer then said “we need programs for children, not childish programs”.

This is exactly what we need for beginners: tutorials that are up-to-date, easy to understand and are based on best practices and proven concepts. Not tutorials that cover easy to explain concepts that actually don’t apply any longer or have to be un-learnt as soon as you become professional developers.

Web competence?

The main reason is that it is hard enough for adults to learn things, but even harder to un-learn them. It is hard work to go through the four stages of competence and once you are at the last you don’t want to start again. However, in a fast paced environment as the web becoming unconsciously competent can also mean that you just don’t realize any longer that there are changes you should be covering.

Lowering the barrier

The main reason people write tutorials that promise a lot and don’t deliver is that they want to lower the barrier of entry for new developers. This is a nice enough idea as web development with all its loosely defined standards and unknowns can be quite daunting at first. However, this to me robs beginners of the chance to become great developers.

My personal idea of a good developer is showing the urge to understand and apply – showing the dedication, interest and stamina to learn about the environment you apply your work, not only the technicalities of it. This comes with experience but it also needs to be based on a good foundation.

Leaving them hungry for more

A good beginner’s tutorial should actually not give beginners solutions but make them understand concepts and point to information they can use to learn things for themselves. There is no greater way of learning than finding it out by yourself, on your own terms and in your own time. Anything else is just repetition.

The why of beginner’s tutorials

There are several reasons why people write beginner’s tutorials:

• They want to genuinely help other developers to come in and start learning the right way
• They want to avoid people being scared of learning the job
• They want a quick win – write about the easy stuff
• They want to show off their skills to lesser skilled developers
• They want to have a big audience – promising easy solutions makes for a lot of readers (think of tabloid journalism)

Not as easy as it seems

Now here is the tricky bit: writing a tutorial for beginners is actually a lot harder than writing about a more complex subject for a competent audience. The reasons are:

• you can cause much more damage with bad information – people trust you to be an expert and will believe and repeat what you said
• you will not get much constructive negative feedback – people will not dare to say you are wrong and the ones that could will not read what you wrote – as it is for beginners.
• it is easy to start with a preconception of what a beginner is – however beginners could be people that are just coming from another area of expertise they are very competent in.
• you don’t have a passion to work with – beginners are mostly scared or try to find a fast solution rather than true understanding

The last point is exactly what a lot of bad beginner’s tutorials work with and writing those will actually make it easy for you to get published. However, it will not make you a good trainer or writer, no matter how good the short term feedback and success is.

Danger signs

I know there will always be a lot of tutorials like this, as the number of hits / diggs and quick fame is important to people to make a name of themselves quickly, but I sincerely hope that this quick rant at least makes you reconsider doing another tutorial that starts with some of the classics like “XYZ in 10 minutes”, “quick solution for XYZ”, “ABC makes XYZ easy and fast!”, “You don’t need to understand XYZ when you do it the ABC way” or “XYZ in one line of code”.