Christian Heilmann

You are currently browsing the archives for the General category.

Archive for the ‘General’ Category

[Job] Help create the Windows version of Framer – React developer in Amsterdam

Wednesday, April 18th, 2018
TL;DR: Framer are looking for a React developer based in Amsterdam to create the Windows version of the app with help from my team. Apply here.

Framer is only available on OSX

One of the things that annoy me the most is operating system dependence. It is frustrating to see a great new tool you want to use but it isn’t available on your platform. Not everyone can afford Apple hardware or wants to do everything in Windows or Android. I personally use several operating systems and it annoys me that I can’t use the same tool stack. Instead you need to learn different ones for each OS (Keynote/Powerpoint anyone?). It feels like the 90s.

That’s why I was happy when Framer contacted me and asked me to help them find someone to work on the Windows version of their great tool. The great news is that you’re not only going to work for a cool company. You also get to work directly with our team here to ensure that the port is going to be a great product. At Microsoft we have a dedicated team helping people to port apps. This team has deep insight into what to do and what to avoid to create an app that takes advantage of the things Windows 10 offers.

So, if you are:

  • A React Native developer who wants to build a great, well-used app for a big community
  • Have Windows experience and supporting more than Chrome/OSX in your WebView
  • Look for a full-time position in Amsterdam, The Netherlands

Apply now, and we can soon bridge another support gap that that is well over-due.

This is a short time offer, Framer are looking to hire someone ASAP and bring out the Windows version within a few months. The new Framer version is close to Alpha release internally.

This was FrontendNE 2018 – well, from my POV

Tuesday, April 10th, 2018

Last week I swapped the 18 degress in Berlin with snowy rain in Newcastle, England. Why? To attend the 2018 edition of the FrontendNE conference and I am happy that I did.

The plane taking me back to Berlin

All in all this was a lovely, cozy and well-organised event. As an extra, it had an audience you don’t come across at a lot at other events. The reasons were threefold. A good location – the big hall of a brewery with proper stage audio equipment. A very affordable ticket price. And the loveliness of the organisers with a no-nonsense MC demeanour and not a hint of arrogance.

The crowd at the event

I like single-track events. It means the organisers have to work harder to ensure each slot is a winner for the audience. In this case, the line-up and topics were diverse and there was a lot to take away.

Val Head : Choose Your Animation Adventure

Val is a well-known authority on anything animation on the web. She has authored quite a few books and courses on the topic. And she teaches people to make things move without making your users queasy or drain the battery of their devices. In this talk she explained different techniques to animate on the web. Starting with CSS animations, past vanilla JS and up to animation libraries. This was a very pragmatic talk explaining the pros and cons of each technoloy with warts and all. Val is a very chipper and engaging speaker, and I am happy she thawed out the audience as the first to step up. Looking forward to the video.

Léonie Watson : You’re only supposed to blow the bloody doors off!

Leonie showing off screen readers

Leonie is an accessibility expert giving sensible and actionable advice on how to create accessible interfaces on the web without overshooting the mark. Yes, there is such a thing as adding too much to make your widgets accessible. Often adding a lot of ARIA also means it is your job to make it work with all kind of assistive technology. Something you can avoid by using the appropriate HTML elements and guiding the user. Hence Leonie’s talk, a nod to The Italian Job. Leonie is a superb presenter. It is great to see a visually impaired person wield stage technology and presentation software as if there is nothing much to it. I liked this talk as it fell neither into the “legal accessibility” nor the “everything works if you only use $thing” camps. Instead, Leonie showed that accessibility is like any other thing. It is a matter of looking into what you are doing and trying your best to make it work. Often this means doing less and the simple thing instead of trying to cater to needs you can’t even know about.

Jack Franklin : A red LEGO brick is always red: components on the web

Jack Franklin is a development lead at thread (the company partly responsible for my swanky style). He showed how they made it much easier to maintain and improve this product using a component approach. Web components are nothing new, of course. Making them work and perform in browsers natively is still trickly though. That’s why many component talks are about the framework du jour and opinionated. Jack did a great job not falling into this trap but showed the real benefits of components. For example hot-fixing a display issue with the certainty that you won’t affect the rest of the page. A great, no-nonsense talk about the subject, well worth a watch.

Niels Leenheer : Having fun with WebBluetooth

Oh how I rooted for this talk to work. Niels is a lovely person and oozes having fun playing with technology. That’s why it was grim to see this talk’s tech demos fail at the Halfstack conference in London earlier this year. Niels still managed to make it a good talk, but seeing him lug lots of hardware to an event just to see it all fail because of connectivity issues was grim. In essence, what Niels proves with this talk is that the specification of Bluetooth and Low-End Bluetooth is a terrible mess. And that with borderline self-flagellating reverse engineering you can do fun things with Web Bluetooth. It is a mess with a lack of standards and at times a total disregard for security. But Niels did a lovely job getting us excited anyways. Top tip though: do not fly back with him as airport security doesn’t like his suitcase full of Bluetooth marvels.

Sara Vieira : Your brain does not have a fix flag

Sara explaining that is hard to be normal

Sara’s talk was the big surprise. It wasn’t a tech talk, although she is highly capable of giving those, too. It was instead a no holes barred account of her life story dealing with and overcoming anxiety. A very important talk about a mental health issue that is tough to understand for people and hard to empathise with. I hope that the video of this will do the rounds and inspire people to care more and those affected to find the strength to find help.

Ian Feather : Frontend Resilience

I wished I had seen more of this talk, but I was bricking it as I was up next. Ian works for BuzzFeed and showed the many ways they ensure the site stays up even when everything is against you. Instead of having a “this is how to make your site performant and everything will be rosy” Ian talked shop. CDNs not working like you expect them, data feeds timing out, the whole horror show of network connectivity. I’m looking forward to seeing this.

Chris Heilmann : 7 things you can do to become a happier JavaScript developer

Hated it. Knew all the content. Boring. Also, what’s with that accent?

General conference feedback

Everything worked nicely and people were very well fed and watered. Actually there was a lot of yummy food left over, which was a shame. The timing worked out, the breaks were well-timed. The location was gorgeous with a lovely park outside full of dogs and swans and their interplay.

The after-party was at a location that had pool billiards, minigolf, bowling and many other things. The food was plenty, two vouchers for drinks ensured that people got merry and charming and not annoying. I only used the bowling lane as I had a lot of people come up to me and ask me questions. I heard from witnesses that parts of the sounds in the karaoke room violated the Geneva convention but that may have been hearsay (or what’s left of the hearing).

The self-demeaning jokes of the organisers on stage, “turns out using sketch for print wasn’t the best idea, just imagine those missing letters” showed that this event was a labour of love and not a way to make money. I like when an event outside the usual spaces for events works out that well. I have the same fondness for Beyond Tellerand, as Duesseldorf isn’t a hub of web news either. I am very happy to have contributed to this event in Newcastle and hope that more will come soon.

What comes after senior developer?

Monday, April 2nd, 2018

This is also Cross-Posted on Medium if you want to comment there.

A few weeks ago a company approached me if I’d be available to give a series of talks and Q&A for senior developers. Their question was how to deal with the problem that there seems to be an upper limit to technical careers. At one time in our career we have a decision to make if we want to keep being technical or moving into management. It sounds odd, but there is a lot of truth to it.

A gap in company hierarchies

Throughout my career I found that there is a limited amount of levels you can climb as a technical person. This sounds unfair, especially in companies that pride themselves on being technical. The earlier you are in your career, the more annoying this seems.

When we start, we love being developers. We see technology solve problems in a logical and enjoyable fashion. Much less icky, slow and error-prone as human communication. It makes us believe that you can solve everything with technology. Which is great, as this is also what excites us. People excited about their jobs work better.

On the whole we earn good money, have a high-quality work environment and feel we could do this forever. Sometimes we get too excited about developing. We don’t realise that we burn out or are being taken advantage of. I’ve seen product managers trying to make a mark by releasing a product before the deadline. They then coerce junior developers to work too much or cut corners. At the cost of endangering the quality and even the security of the product. And the mental health of the developer.

Seeing this dedication it feels weird not to have technical role models to look up to. At a certain level in the company it seems you need to stop coding and do things we don’t like to do instead.

What annoys us?

We love to complain about things at work. As developers we are quick to blame things beyond our control for failures. It can’t be the problem of the technology or our skill, right? We’re excited about what we do, and that means only good things can come out of that.

Often we see products go wrong. Most of the time because of business decisions that make no sense to us. Business decisions that interfere with our development plans. People get allocated elsewhere, budgets of exciting products get cut. Products we’d love to see go live as their technology is cool and innovative.

Meetings are plentiful, not productive and get us out of our development zone. Why should I sit in a room talk about what I do when the version control comments do the same job?

Time and allocation estimations keep being wrong. Either we’re allocated to a project that doesn’t need us, or we don’t have enough people. We run out of time when developing products and often by the time we release, the market stopped caring. Or our competitor was faster.

Whilst underestimating it ourselves, we often see other engineers burn out. There is a huge churn of people and it is tough to build teams when people keep leaving and new ones get hired. It is hard to keep up good quality in a product when the team keeps changing. It is tough to innovate when you spend a lot of time showing people the ropes. And innovation is something our market seems to be running on. It is also what excites us as developers, We want to do new, cool, things and talk about them.

We face the issue that we keep having new people but there is never enough time for training. When we read the technology news feeds there seems to be so much to look at but it is beyond our reach. Instead we spend our time re-educating joiners on how things work in our company. And it feels that we ourselves fall behind whilst our job is to be inspiring to junior developers.

What are we worried about?

As developers in the trenches and in the flow of excitement we worry about a lot of things. We find that keeping up with technologies is a full-time job. If you’re not on the bleeding edge you will only get boring work or someone will take your job. This is odd considering the amount of job offers we get and how starved for talent our market is. But we worry and we stress out about it. Younger, fresher people seem to be much quicker in grasping and using new tech as we are.

We also see coding as a fun thing and we don’t want to stop doing it. We remember that we had no respect for people who didn’t write code but use products instead. We don’t want to be those people, but it seems that to advance our careers, we need to.

Turning the tables

It is a good thing that these thing annoy us as they are an opportunity for us to turn the tables. By shifting into a role that is a technical hybrid you can battle some of these annoyances. The hierarchy gap is an indicator that there is a rift between the technical staff and management. A gap that is costly and hinders our companies from innovating and being a place where people want to work.

It is painful to see how clumsy companies are in trying to keep their techies happy. We do team building exercises, we offer share options. We pay free lunches and try to do everything to keep people in the office. We print team T-shirts and stickers and pretend that the company is a big, happy family. We pay our technical staff a lot and wonder why people are grumpy and leave.

All these things are costly and don’t have the impact our companies hope for. The reason is that they lack respect and understanding. When the basic needs of humans are met there is no point adding more creature comforts. There is no point earning more money when you have even less time outside work to enjoy it.

What gets us going is a feeling of recognition and respect. And only peers who’ve been in the same place can give that. There is no way to give a sincere compliment when you can’t even understand what the person does.

And this is where we have our sweet spot. Our companies struggle for relevance in comparison to others as much as we do with out peers. And often they lack input from us. Instead of implementing what has always been done a certain way we can bring a reality check. The market keeps changing and it is up to us to remind our companies what excites technical talent.

There may be a path already available to you – or you have to invent one to do that. In any case, your first job is to become visible to your company as someone who cares and wants things to change. This means partnering with HR, hiring and PR. It also means selling yourself to management as someone ready to change things around.

Becoming a fixer of bigger problems…

The fun thing to remember is that as a company in the technology space, everybody has similar worries. Think you are worried about falling behind? Your company is much more worried, and you are closer to the subject than the people running it.

Research what worries you, share how you keep up to date and what it means for your company. It makes sense for a company to get the gist of a new technology from someone who can verify it. A lot more sense than falling for a hype and buy a third party product or consulting on the subject.

Often we’re asked to implement something hot and cool that doesn’t make any sense. The reason was most likely some PowerPoint circulating in upper management. A presentation based on what excites the tech press and not what makes your product better. Try to be there with advice creating that PowerPoint before you have to deal with its impact.

Retention of talent is another thing every company worries about. Churn and burnout of engineers is a big issue. Try to offer solutions – things that help you and keep you here. Every engineer coming through the door is a 20,000 GBP investment. Even before they wrote their first line of code or got access to the repository. Every engineer staying at your company is a worth-while investment. Making sure you help find your company ways to keep people is a big plus for you.

Another way to shine is by bringing in new talent. It is a competitive market out there and it is hard for a company to find new engineers. As developers we’ve grown weary of terrible job offers. It is not uncommon to see demands like five year experience for a one year old technology. You can help prevent your company from such embarrassment. Work with your hiring department to draft sensible job descriptions. Even better, go to events and meetups. Look through pull requests and comments on repos to spot possible candidates.

Find ways to encourage your engineers to hire by word-of-mouth. This is is how I found my last five jobs and this is also how I made up for some income gaps. A company that pays a bonus for each hired person has employees as advocates. People we trust are more likely to be good colleagues. Better than random people you have to filter out with a good interview process. Try to make your company visible where developers are by being a great example, and you may stir interest.

Nonsensical job offers are a symptom of a general problem with internal communication. This is rampant in our market. Developers hate managers, managers don’t get developers. You can mediate. It is a tight-rope walk at times as you don’t want to come across as someone trying to please management. But it is a necessary step, and if better communication is the result, worth your time and some arguments.

External communication and marketing is another department you can help with. How often did you facepalm reading advertising by your company? Help avoiding this in the future by being a technical advisor.

Overall, this is about being an ear on the ground for your company. To non-technical people in a company navel-gazing is common. The job of marketing is to make your company’s products look good. Often this means that people get a bit too excited about your own produce. They don’t compare, they don’t even have time to look at what others are doing. This is a good chance for you to keep up with what the competition is doing and tell what it means to your company. You’ve done the research for them, and that is worth a lot.

New skills that are old skills…

The fun part about being a coder is that you don’t have to deal with people. This ends when you want to move further up. Your “soft skills” are what will allow you to stay technical and have a new role. Your technical skill is an asset, but it is also limited – even when you don’t want to admit it yet. Being a technically skilled person with good communication skills is the sweet spot to aim for. The higher you communicate upward, the less people are interested in technical details. Instead they want to see results, impact and costs.

Sales people know that. Learn from how they work, but stay true to what you talk about. Instead of selling by hushing up bad aspects, sell your technical skill to prevent mistakes. Instead of bad-mouthing your companies’ competitors, be in the know about them and show your company what to look out for. We all sell something. Why not sell what excites you and your experience instead of having to patch what others messed up?

Flexibility is the key

My career took off when I stopped caring where and when I worked. Being open to travel is important. Most communication problems in companies are based on time difference. Be the one that is available when others are. Try to be open to any technology and listen to their benefits and problems. You will not live and die in one stack.

Things not to worry about…

You are not betraying the brotherhood of coders by moving up. They have no wrath worth worrying about. You will be asked constantly if you still code. But it is natural that you will lose interest in being on the bleeding edge all the time and doing the work. We all slow down and want a life besides chasing the cool. You will also wonder why the hell everything is so complex now when it used to be so simple. Even when you don’t code all the time, you won’t be bored. Consider this a chance to fix what always annoyed you.

You will be praised for things you haven’t done. Much like you are praised as a developer for things you don’t consider good. People can’t measure what is good, they see what you do and are impressed. Take the praise but make sure to share it with those who did the work.

Realities to prepare for…

Let’s re-visit the worries we have as developers and give them a reality check.

Keeping up with technologies is a full-time job. It is! So find a way to convince your company and managers that you are good at doing that. Remember that you need to free up a lot of time on your schedule to do that. This means not doing all the work but getting better at delegating. It also means giving more conservative estimates about your deliveries and deadlines. This can be tough to do. Especially when you made the mistake of establishing yourself as the person who can get things done – no matter what.

You can only understand a technology when you use it. True. But you will never have enough time to do that. Triage the evaluation and using of technology to your team. This is a great way to empower people and allow them to work on their communication skills. It is also a good way to keep your team interested. Allowing a developer to stop ploughing through a bug list and evaluate something new and shiny instead feels good. If you rotate these assignments you don’t cause jealousy or show favoritism. You don’t want your team to feel bored or underappreciated whilst others do cool stuff. So let them do cool stuff and keep buffers in your allocation planning that allows for it.

Younger, fresher people seem to be much quicker in taking on new tech as we are. True. So allow them to do that and be a good leader for them. You will get slower the older you get. You will be hindered by real life demands. The more experienced you are, the more likely you are to discard new things and stick to what you know. Let others inspire you. You might not be up to going all-in with some experimental technology. A younger person reporting to you can be and you can learn something by guiding them.

Coding is fun. We don’t want to stop doing that. True. You should never stop coding. But isn’t it time you earned the right to code what and when you want to? Things you know well are a great opportunity for a junior developer to learn. Don’t take that away from them. We shouldn’t be bored by our code. This leads to stagnation and is the antithesis of innovation.

We remember that we had no respect for people who didn’t write code but use products instead. I sincerely hope you grew up. Software Development is a service. We build things to empower people to achieve goals. The more complex these systems are, the more we move away from coding. There is no medal for being hard-core. First to market is a thing.

Other realities you have to face are things you may not be familiar with or you are in denial about. These things happen though – all the time.

There will be a time when you are too senior to be assigned work. You might as well take action on that. Make sure that you have junior engineers you trust to do that work and be the firewall for them. When you are too senior to do a job, make sure you help the product owners find the right people in your team. Your job is to take the demands from top down and translate them to manageable chunks for your team.

Anything you do can get canned at the last moment for reasons beyond your control. Take it in stride and learn from the mistakes you made. Be stringent in noting down what went wrong. That way you don’t repeat the mistakes.

You are diving into the deep end of corporate politics. Who you know, and who you impress is often more important than what you know. Networking internally is a big thing. Concentrate on corporate levels, not on individuals. People leave.

Things to start with…

I hope you found some things that resonated with you here. There are many ways to get into a place where you can stay technical and move up in your company hierarchy. Most are fresh though and companies need to change age-old approaches to the topic. It is exciting to be part of that change though.

A few things that helped me get to this place are kind of obvious:

Consider contributing to open source. Either by participating in projects or open sourcing your own products. Open source is by default a communication channel. It helps you find talent as people join your company knowing your product. It helps your company become more visible to developers. And it gives your team a sense of achievement. Even when some internal product goes pear-shaped, there is something out there. Even when people leave the company, they have something to take with them. Contribution to open source is portable. You can show the outside world your skills – no matter who pays your wage.

Look for events and meetups to attend. Instead of taking your team to the bowling alley or an escape room to do team bonding, why not attend an event? You learn something, you can talk to people about your work and you get out together. Many events also offer jam sessions or B-Track events which are a great opportunity to submit a talk. Of course, you can also host a meetup or guest presenters at your office.

Foster an internal culture of communication. When you get people to attend events on company time, ask for them to present about the event in the office later. This helps with a few things. It means you know they went there and paid attention. It means others who couldn’t go get the information. And it means your team already gets used to presenting to a group which is important later in meetings. Often technical people know solutions, but don’t speak up in meetings as they don’t see the point. The more we get used to it, the more we embrace the idea that our points only get rewarded when we tell people about them. There are many ways to foster communication and some are a lot of fun to do. Like lightning talks about solved issues in products or even something as silly as Powerpoint Karaoke.

Aim beyond the finish line

The main thing to remember as a senior developer struggling with having no role to aim for is to aim beyond that role. Your company invested a lot in you and relies on your judgement when it comes to technical delivery. It also relies on you to lead a team and keep them happy. You also deserve to be happy and to make that happen you can’t keep things as they are.

One of the biggest mistakes we make as technical people is to make ourselves irreplaceable. We put a lot of effort into our technical products and it is hard to let go. Often we stay in a position even after all the joy went out of it and we don’t believe in the company any longer. Because we want to finish that project and see it go out of the door.

The seemingly sad fact of the matter is that nobody is irreplaceable. And that project the company keep stalling on isn’t going anywhere. And if you left to pursue other things not everything will go to pot, either. The main step to get ahead in your career is to understand that. You are replaceable and you have to take an active role in it. Hire people that are technically better and more interested in new tech than you are. Don’t be afraid of them moving into your role. Instead support them and find worthy replacements. Change in companies is a given, you can be part of those driving it or worry about how it will affect you. I’ve always rolled with the punches and it served me well. Hopefully you can do the same.

Ink-trap development

Thursday, March 1st, 2018

Sometimes you see things that look a bit off and it makes you feel uneasy. When something challenges your sense of quality and what appears well-made. Like the following font:

Bell centennial demo

This doesn’t look good, and it doesn’t look right. It feels like someone didn’t quite finish it or didn’t know how to use tools. Or – even worse – didn’t use the right tools for the job. This font, for example, looks like my first attempts to get my head around vectors in Photoshop. Not a memory I cherish.

In the case of this font, though, nothing of this applies. What you see here is Bell Centennial by Matthew Carter, a well-regarded font expert. It is a font that has seen a massive amount of use.

You may not recall ever seeing it, but here’s the deal: Bell Centennial was the font used in AT&T phonebooks. The weird missing parts of the letters in it are so called “Ink Traps”. The genius of the ink trap is that it makes the font work when applied in its natural environment.

inktraps

Phone books shouldn’t cost much to print, which is why they use cheap paper. They also are big and should use small fonts, allowing for more content in fewer pages. In essence, the implementation phase of the project phone book tried to cut corners. Staying as cheap as possible.

This is where the ink traps come in. Ink bleeds out on cheap paper and blurs the letters. A font with no spaces can thus become unreadable. Not so Bell Centennial. On the contrary – it gets better and more legible when printed. The ink traps fill with ink and make the weirdness of the font go away.

M in design and in print

Bell Centennial in use

I like this approach a lot. There is a lot of merit in creating something and assuming a flawed implementation. As they all are in one way or another. By leaving things out to become available later – or not at all – we can concentrate on what’s important. A solid base that may not be perfect, but will not expect the implementer to do everything right, either.

Because they never do. In twenty years in this industry I’ve never seen a project get out the door the way we planned it to. It was even more common to see projects getting cancelled halfway through. And not only waterfall projects. Even the safeguard of the Agile Manifesto keeps failing.

In-build failure obscured just enough to make money

When I worked for an agency in the B2B space this seems to be even a common theme. Get the project, make sure you have a nice round sum in the contract that you have to pay in case you fail. Then pad the project with lots of unnecessary but expensive heads in the early stages. Bill all those to the client. Mess up and pay the fine when everything goes pear-shaped, leaving you with a nice profit.

We want to build for the future…

As a technical person, these projects were frustrating to work on. We’re lazy. We don’t want to do the same things over and over again. We want to do something and then automate it. We are all about making sure what we do is maintainable, extensible and follows standards. Because that makes outcomes predictable. For years we’ve been preaching that our code should be cleaner. It shouldn’t make assumptions. It should allow for erroneous data coming in and trying to fix it. It should be generic, not specific. We preach all this to avoid unpleasant surprises in the future.

Future imperfect

And yet, I have a hard time remembering when projects that we put so much effort in ever became a reality. They got out, yes, but somewhere along the way someone cut corners. And what is now live was never something I was particularly proud of. Other projects, that appeared rushed and made me feel dirty got out and flourish. Often they also vanished soon after, and oddly enough, the sky didn’t fall on our heads. Nobody missed them. They’ve done their job and overstayed their welcome. It was wasted effort to make them scale to forever and try to predict all the future needs. As there was no future for them. It is easier to fold and restart a software project than to dismantle and change a physical product. That’s the beauty of software. That’s what makes it soft.

I’ve hardly ever seen rewards of the hard work of making products maintainable in a clean manner. I am not saying they don’t make sense. I am saying that far too often, something got in the way. Something I had no control over. Often things I didn’t even hear about until things went pear-shaped:

  • Our well-thought-out design system hardly ever evolved with the product. Instead redesigns would wipe them out completely. Or the product would move to another CMS or backend. Out of a sudden this brought new limitations incompatible with the original design.
  • Our clean, accessible and semantic templates have a similar fate. Tossed around a few cycles of maintenance someone will have removed or warped the goodness we added upfront. Audits will flag this up, but with no immediate repercussions the invalid bits will end up on the backlog. There’s new things to add, after all.

New toys with new battery requirements

A common scenario is new product owners trying to make their mark by bringing the new tech hotness. Hotness they don’t understand and don’t hire able people for. Instead, it means starting new and following the “best practices” of the new hotness. What works for Facebook will also scale and apply to this internal payroll system, right?

Is failure a given? Maybe…

I’m sorry if this sounds bleak, but this seems to be a good time to re-consider what we are doing. We had a few decades of computers turning from a tool for scientists to them becoming an integral part of life. And this means we need to level up our game. This is not a cool tech thing to play with. This is a integral part of life. People’s identities, freedom, security, safety and happiness are dependent on it.

Broken toys

The quality of what we rely on isn’t that encouraging. If anything, a lot of the sins of the past now come to light – even on a processor level. We built a lot of spur-of-the-moment, good-enough things and hoped nobody looks closer. Well, the bad players of the market seem to be the ones looking and taking advantage.

When in the past we hid odd code in obscure byte code we now create huge dependency chains and lots of components. Components easy to re-use. Components not under the scrutiny of any quality assurance or security audits. Instead we rely on the wisdom of the masses and the open source community.

This would work, if the OSS world hadn’t exploded in the recent years. And if we didn’t tell newcomers to “not worry” and “just use what is there” to be more effective. We’re chasing our tail trying to be more effective and creating a lot with not much code. We move further and further away from the implementers and maintainers of our code. That’s what abstraction offers. Nobody likes maintenance. But it is probably the most important part there is. Any non-maintained project is a potential attack vector.

We forget that someone, somewhere needs to ensure that what we do doesn’t become a security nightmare. Instead, we create tools that check existing solutions for problems after the fact. This is a good measure, but it kind of feels self-serving. It also assumes that companies care to use these tools. And how they use it.

Case study: when the law required accessibility

I remember accessibility going through the same motions. When being accessible to people with impaired abilities became a legal need, people started to care. They didn’t care enough to look into their process of creating accessible products, as in – start with a sensible baseline. They didn’t want to understand the needs. They wanted to know how not to get sued. They bought a tool to check what’s obviously broken. They displayed a “Bobby Approved” or WCAG-AAA compliant banner on their web sites. They achieved that by adding alternative text like “image” to images. Satisfying the testing tool instead of creating benefit to visually impaired users.

This enraged the purists (including me) as it showed that people didn’t understand why we wanted things to be accessible. So we ranted and shone bright lights at their mistakes to shame people into doing the right thing. The net effect was that people stopped reaching out to experts when it came to accessibility. Instead they hired third party vendors to care on their behalf and build the thing needed to not get sued.

A lack of shared responsibility

It makes you wonder if we are trying too hard. If the current messy state of affairs in the whole of IT is based on a lack of shared responsibilities. Communication doesn’t help if it only states “don’t worry, it works”. An “of course our product will scale with you” is worrying without any shared ownership of the “how”. There is a disconnect between what we build and who maintains and uses it that leaves everyone involved disappointed.

This is tough to swallow and does rattle a few basic pillars of how we make money in the IT world. We build products and frameworks that enable people to do their jobs. We don’t want them to mess with the products though, so they become very generic. Generic solutions are less likely to give an optimised experience. They also are less likely to result in performant solutions catered to the current need. We throw in the kitchen sink and the plumbing and wonder why people run out of space. And we get angry when they start fiddling with the wrong pipes or don’t fix those that leak as long as the water runs.

Many products are terrible, but everyone involved didn’t do anything wrong

We’re quick to complain about users not doing things right. But we also never cared much about how people use our products. We hand this task over to the UX people, the trainers, the help desk and the maintenance staff. It is easy to complain about systems we have to use and wonder how on earth these things happened. The reason is simple: we created generic solutions and tweaked the output. We didn’t remove any extra features, but made them options to turn on and off instead. Many of our solutions are like a car with five steering wheels in different sizes. We expect the drivers to pick the right one and get cross when they’re confused.

Ink-trap development?

Maybe this is a good time to reflect and consider an approach like Matthew Carter did. We know that things will go wrong and that the end product is not perfect. So we optimise for that scenario instead of offering a huge, generic solution and hope people only use what they need. Maybe coding isn’t for a small, elite group to deliver interfaces to people. Maybe we need to have more involvement all the way from design to use of our products and we will create what is needed. This means that a lot more development would be in-house rather than buying or using generic solutions. Sure, this will be much more boring for us. But maybe not trying to predict all the use cases people might use our products for will give us more time to have a life outside of our work.

Working in IT isn’t an odditiy any longer, it is one of the few growing job markets. Maybe this means we have to dial back our ambitions to change the world by building things people don’t have to understand. Instead, we could try to build products based on communication upwards and sideways. And not those that only get feedback from user testing sessions once in a blue moon. People are messy. Software won’t change that. But it could give people ways to mess up without opening a whole can of worms by sticking to features people really need and use. We can always expand later, can’t we?

Twitter testing out a new “consequences” button? Not really…

Monday, February 26th, 2018

I just had an interesting experience after adding a German SIM card to my phone. The Android version I have told the phone to automatically switch all apps into a German mode. This can be handy, but I found it annoying.

Where it got really odd is in the Twitter Lite PWA-ish app. As it runs in a Chrome WebView the browser tries to be extra helpful and translates the interface back to English. That way I ended up with a “consequences” button, which made me do a double-take:

Twitter with a new consequences button

I thought it is a new way to deal with lots of answers and that you can vote answers up and down. I also was impressed that now tweets can like people, but no. “Follow” in German is “Folgen. And as a noun instead of a verb, “Folgen” in German are “Consequences” in English.

One more thing to worry about when a webview gets too clever for its own good.