Rodney Rehm

I'm not exactly a fan of official job descriptions. In fact, I wouldn't apply to them myself. While I can't do anything about that careers "website", I can share some insight…

My story

Let's start at the beginning. About 5 years ago I got to know Sebastian Golasch at a conference's dinner. That evening I declared that I would never ever work for Deutsche Telekom, after listening to a Freelancer rant about working on a Deutsche Telekom project. A few months later I was contracting on a Deutsche Telekom project. A year later I gave up 10 years of freelance and became a full-time magenta employee. I've been working on this product for 4 years and at the company for 3 years and I have no intention of leaving.

My motivation

I've always wanted to empower people. For the first half of the last decade that meant empowering not-very-technical mid-level managers to manage electronic workflows and data structures. While I certainly learned a lot doing that, I wasn't particularly connected to the product or its users.

I've always been a fan of misappropriation (today we'd call it "hacking"): Modifying tools (software, physical objects) so they can be used for tasks they were not originally designed for.

I grew up with Lego and I write software, so it's natural to think in small (insignificant) blocks that, when combined, solve a problem.

I've found all of that working on this product. A product that actually can change people's lives in ways we may not even understand yet.

My status quo

When I joined the product I saw a number of problems with how things were done (or not done at all). These problems weren't necessarily of technical nature. I wasn't happy with how the product was built. The separation of concerns (on a team level) was wrong. A few things looked like a pile of duct-tape spaghetti. The user experience wasn't great (euphemism). Communication and collaboration wasn't a thing. And. So. On.

I'm happy to report that most of these issues have been squatted since then. 4 years ago we were in "startup" mode, meaning we tried to get things done quick, rather than well. Today we've curbed the "quick" and (mostly) focus on the "well".

It certainly wasn't me improving all of that, but I've had a (Trump-sized) hand in a few of those topics. This led to a certain feeling of ability to improve things for us, the product and the consumer - and that's what's keeping me entertained.

Enough narcissism, let's get to what we work on and how we do that…

What we work on

The general topic is IoT (Internet of Things). My team builds the customer facing web frontends of the Qivicon Platform which is the base of Deutsche Telekom's Magenta Smart Home.

We connect "everyday objects" (e.g. Philips Hue, Netatmo, eQ-3, and lots more) and allow them to communicate with each other. Since these "smart devices" can be rather dumb, it's the web UI's job to make this stuff as simple as possible. In the end we take care of all the UIs for maintaining a smart home.

This product allows people to rewire how their home works - and we are making sure that it's managable by people without a degree in computer science.

The tools we use

We have a number of legacy apps built on top of Backbone and Marionette. New projects are starting with Vue.js. We're planning to gradually move everything over to Vue - and this is something you'd be working on with us. But changing stacks like that takes time, so you'd also help us maintain the legacy apps until they're converted.

The legacy apps use grunt and other prehistoric tools. The Vue stack is built on top of Webpack and offers some of the modern amenities that instantly make you a 10X developer, simply by knowing their names.

We are big proponents of web technology, meaning we favor standards like Web Components over things like React and JSX. If you're looking for Angular, React, Ember or whatever today's framework is, stop reading. You won't be chasing the newest hottest tools with us.

We manage our code in git repositories powered by Bitbucket (formerly Stash).

While the frontend stack pretty much is all JavaScript, we're part of a Java ecosystem. None of us frontend developers really do any Java, but we are using things like Maven and Nexus. Some parts of a website we maintain is written in PHP.

Everyone uses the editor or IDE they want. Some use a GUI for git, but most of us prefer the command line for git (and anything, really). Ultimately you're free to choose the tools you feel comfortable with.

Pretty much everyone here works on a MacBookPro. If you prefer Linux or Windows, you can have that, too.

Team work

Currently we're 4 frontend developers, 2 designers, 3 QA engineers, 1 product owner and 1 scrum master. And we're looking for 3 additional frontend developers.

We're split between Germany and Bulgaria. Ze Germans work in Darmstadt. Some are here for 3 days a week, working 2 from home. Some are here all the time - because they happen to actually live in Darmstadt. We also have offices in Bonn and Berlin, which could be used if you don't feel like Darmstadt is your city. We try to see everyone at the office on Tuesday and Wednesday.

The team communicates (in English) via chat and video conferencing. Official meetings are usually done with WebEx.

We manage our work with Jira and document things in Confluence. We generally try to avoid mail.

Development process

We currently work in Kanban and some of the other teams work in Scrum mode. Our process looks as follows:

1. Designers create their proposals consulting with developers early on.
2. Developers implement things, usually doing another dance with designers.
3. Implementation ends with a code review (pull requests via Bitbucket).
4. Once the product owner signs off, our QA engineers go to work creating automated tests and manually run things in various browsers.
5. If the testers don't find any issues (haha, of course they always do!), our code is delivered to the next stage of QA.
6. The central QA team runs another round of extensive end to end tests on all of the product's systems on a platform similar to the production servers.

Our sprint cycle is 2 weeks. With the QA team "lagging behind" by 1 sprint, our software reaches the customer approximately 1 month after we've written it.

We're working in these stages for a reason. In development and integration we have access to pretty much everything. In production we have access to nothing. We have to go through the proper channels to obtain log fragments from production servers. Data privacy is kind of a big deal around here.

To web developers accustomed to creating web sites the staging concept and the two instances of QA may seem a bit odd. But in a system where your customers' well-being can be at stake, you just can't have enough QA. And even with our setup lots of issues fall through - because this stuff is getting real complex real fast.

What about open source?

The system is based on eclipse smarthome. The project's lead sits in shouting distance. Our Runtime team contributes extensively. They also work on other projects like jUPnP and JmDNS.

The frontend developers don't have any official projects like that. But we've created and shared (and maintain) the odd project like wemo-client, ally.js, sass.js, viewport-units-buggyfill and more. A couple of years ago, when we were unhappy with how we write tests, Sebastian created DalekJS. And of course we've contributed bug fixes to most of the tools in our stack.

What are the perks?

We're not really into foosball tables and stuff like that - so, none of that "useless frathouse fun stuff", sorry. There's all-you-can-drink coffee, water and tea. If you need pop soda, candy or similar, get some at the kiosk downstairs. I'm not sure what to tell you here. I've seen Google's and Facebook's offices. While it sounds fun, I've never missed any of that.

Conference-wise we have different situations. Some of us attend one conference a year, with expenses covered by Deutsche Telekom. Others attend a few more and get that time off, but cover the expenses themselves. In 2016 I'll have attended 8 conferences). We'd be happy to take you along the ride :)

I think everyone has 30 days of vacation. Past 22:00 nobody gets into the office anymore because we shouldn't be working anymore anyway. We're told to work sustainable hours. It's up to us, nobody checks when or how much we really work. But if someone realizes that you're putting in too many hours, you'll be called out on that and asked to take more care of yourself.

I'm not saying there's no pressure to deliver things, but I haven't had to pull an all-nighter since I began working here in 2013. Things are done when they're done. While we may be asked to make something work by a certain deadline, it's far more common to push the deadline or re-define scope of delivery. People are here to create a great product, not to burn out.

Why this job is important

Smart Home and Internet of Things are fairly new consumer markets. Technology and devices have been around for a while, but emerged in silos and often with questionable user experience.

The product we work on is focused on breaking or connecting these silos. Our team is responsible for making the management of these connected devices as intuitive and easy as possible. We empower people with limited technical skills to accomplish technical tasks. We make this stuff usable.

What you'll learn on this job

• I'll be pestering you with semantic html, accessibility, CSS, debugging and understanding browsers. We're working with the "Web Platform", and that means understanding it.
• Sebastian will be annoying you with the newest technologies and performance tricks. We're working in a realm of constant change. While we don't adopt every new technology right away, we do need to be aware of them.
• Timon will share his thoughts on how to write clean and maintainable code. We don't create projects that will be re-created from scratch by another agency 3 years down the road.
• You'll learn that we have things to learn from you, too.

We transfer knowledge mostly through comments on pull requests. Also we have an hourly cigarette break that we use to catch each other up and pick each other's brains. (Not everyone smokes during these breaks, though ;)

What now?

If you're interested in what we're doing and how we're doing it, consider working with us!

On Telekom Careers search for "Smart Home" and chose the profile that suits you best ("Software Entwickler" also applies to the frontend positions). If German isn't your language, or you have questions, ping me on twitter.

---

Twitter pings

These questions popped up on twitter:

• Do I need to know JavaScript? Yes. It's about 80% of what you write. We create reusable components, that once done mean we don't have to touch the HTML or CSS anymore. You won't need to invert a binary tree on a whiteboard, but you definitely need to know your way around JS.
• Can I work from remote? Yes and no. As an employee of Deutsche Telekom you need to be "stationed" at one of its offices. In our case that's Berlin, Bonn or Darmstadt, where you'll have to spend 2-3 days of the week. (I don't live in either of these cities, but not everyone is comfy with living in hotels…)