The Dangers of Being a Web Developer

Web development is an amazing field—easy to get into, straight forward to grow skills, great to build a reputation. The sky is the limit. It turns out, being a web developer is not all roses: on great opportunities that lead to obscure problems that ask for humble solutions.

Transcription

[Digital music]

[Applause]

Jens Oliver Meiert: Thank you. It’s an enormous pleasure for me to be here today. When I rehearsed and went over the talk, at first, I was wondering whether I should say something along the lines that I’m not sure whether I’m throwing Marc under the bus or he’s throwing me under the bus here. So, we’ll see how this turns out.

I’m Jens. I’m a Web developer, and I want to start very simple here. The simplicity here should probably start with that I only want to say that I’ve been in Web development for about 20 years now. I worked for small companies, for medium-sized companies, for larger companies. And, I had the pleasure to work freelance and as a consultant, to work on my own projects and on other people’s projects, all of that, researching a bit, and publishing - blah, blah, blah.

The only thing I want to say with that is, I feel grateful that I got to get to know our field from a variety of angles. I’m very happy about that, and I’m happy about that particularly because I think our field -- and, I like to be liberal with terms sometimes. Some people might call that quite imprecise, but I like to call it liberal that I also lump together Web development and Web design at times. Here, I want to keep a development focus, but don’t mind me sometimes bleeding into Web design as well. I think, overall, that is one thing I want to emphasize here now in the next few minutes is how great of a field we are in and how great the neighboring fields are.

Also, a thing that I was wondering about when preparing this was whether I should really keep this metaphor that I had in my mind. It’s one that I stole from someone who is talking to writers. I like to read a lot, and I like to pick up books on any kind of subject. As I publish, and as I write a lot, I picked up a book about writing. This book was by Rachel Aaron, I believe, and was one of those heavily promoted books on Amazon. I read it, and I took a few things out of there. Overall, it contained some nice advice.

And then, one metaphor stuck in my head because I feel like not only am I a terrible person to tell jokes; I don’t always feel like I can tell good stories. And so, she used the metaphor of, if you want to tell a story, you take your characters, you put them in a tree, and that is supposed to symbolize at least you can pick one tree there. You put it all on fire, and then you try to save your characters.

I later thought, like, is this is a good way of structuring a presentation? I didn’t think about it any further. That happened, and so I started with that. We would put some things into a tree.

There are five things or families of things I want to emphasize in this first part, things I find exciting about our field, about Web development and design. Also, when starting to prepare, I thought, like, well, the first thing to notice is how it’s really easy to get into our field. The first thing to come to my mind was that there is low equipment cost, for instance. Anything with a screen would do; any computer with a screen would do.

Now, that seems a bit very simple, so I thought the next good thing would probably be that it’s really easy for us to start, to get into our field. I’ve made the mistake in earlier years that, whenever people approach me about how do I learn Web development, how do I learn Web design, I scared them by telling them, “Read the specs. Go and read the specifications.” Then people normally left and went elsewhere.

It’s still something that I try to not give this advice anymore. But, what I like about this is, if you think about other industries and other fields, then you notice that oftentimes it’s much more obscure and much more expensive to actually get to excellent sources in order to learn a craft. I think we’re kind of, well, at first, I thought privileged, but that would push it, probably. But, we are in a great situation that we do actually sit on heaps of materials of excellent quality for free, so specifications and RFCs. Dry as they may be, they’re still excellent in order to start getting into our field.

Then, for practicing, that, of course, is also very important for us in order to actually learn our craft. For practicing, there are also a host of interesting options, I think. The first one probably being that it’s very easy to just work with local tests and local files. We can fire up text editor to a key and doctype HTML, title foo, P bar and, as you can tell, I’m alluding to a very simple form, but valid form, of HTML that you can then save and open your browser. Then you see, like, bar, like as we just keyed in the content for a paragraph. It’s very simple. To this day, by the way, whenever I want to test something CSS or something like that, I just work with setting files, local files, local tests. It’s very simple and quick to do.

Then another thing that is, I think, a nice peculiarity or characteristic for our field are, of course, that we can use and work with our own websites. If I can get a quick show of hands who here has their own website - that is a good number. I feel like you would all know, from your own experience then, how this doesn’t just start with the practice that you get by running your own website, but it starts, I think, with a deeper commitment. You own your own site. You feel responsible for it. You feel committed to it, and then starts all that practice that you get. Be it that you start and, that, by the way, these days is my recommendation really for people who want to get into our field to actually start with our own website because of the commitment, because of the practice we get, even when it’s just a business card type page. Even that can be useful. The commitment, the options that we have to try things to design, to code, to work with something that we own, and that we identify with, to some degree - hopefully not too much.

Then, of course, we have other people’s websites. I think, ironically, at first, I thought I’d make a snarky remark about that how we run other people’s websites and sometimes bad things happen there. But, that would be a bit too much because normally very good things happen with that because, yes, we do practice and, yes, we also sometimes need that as a playground, too, in order to grow and learn as professionals. This is useful, but it hones our skills and we’re mostly in the line of working with other people’s sites. And so, there are all these practice opportunities, which I believe are actually unique about our field.

The really special thing then about Web development and design, I think, is the great power it really comes with. Also, at first, I thought about, should I go and talk a bit about full stack stuff? I do struggle a bit with that term, and I do struggle a bit with that term when I pick up books. Again, I said I like to pick up random things. There was this book lately, a great list of resources about front-end development, and the author tried to define full stack development and said, “Well, it’s really hard to define.” That is, of course, not the real definition then for something, but it felt to me like, yes, that is a bit unclear.

The worst thing for me was always the implications a term like this may have for quality. If quality is a priority for our work because, if you have a blurry term and you throw in a host of technologies, then does that all imply that person is an expert in all these technologies? It would be an interesting thing. But, it’s not that important here, really, because I think we have a much better term, a much more interesting term, and a much more powerful term that we can inherit, ironically, from the agency world where it’s about full service.

I find full service really, really, really interesting because full service, first and foremost, means--in the agency realm--if someone needs a new website or an app, you develop a concept, you design, you code, you deploy, and you launch. You monitor, you optimize and, if you’re lucky--I like to be a bit cynical about things--when you are lucky, then it also gets maintained. Of course, in the agency world, this is tricky because normally you need maintenance contracts - blah, blah, blah. Maintenance in the agency world, to me, seems always a bit tricky and difficult, but more from a client angle, actually, than from an agency angle because, from a client side, you need to think about maintenance going down the road, in many cases.

But, back to full service. As professionals, as people working in our fields, many of us, I would venture to say, work either for agencies at some point in their career, they work with agencies at some point in their career, or they run their own websites, as we’ve just seen, like many of us here. In these capacities, we do touch on this. I believe we are all familiar with this to some degree. We all write some concept or have some idea about something conceptual at times. We do design. We develop, when we have this development focus, of course. We do code, we bring stuff online, we monitor, we optimize, and we market and everything.

I think all of us have a full-service kind of profile. Yes, to varying degrees. Some of us are -- well, let’s assume developers will normally have their strength there. Some of us have also a certain design background or are even stronger there. Others will find it easier to, say, optimize something whether that’s for search engines or for conversion or whatnot. Then others, yeah, have again different profiles. For me personally, I guess I tend to always overestimate my design capabilities, but I’m definitely very sure that I have no marketing talent. There, I know where I stand in the full-service realm, a little bit at least.

The thing, again, is the power now. When we have an idea about something, about an app or a site, we are in the situation that, for us, we can quite possibly actually execute it, quality considerations left aside now. Or at least we know, for the things that we can’t do, who we can contact, who we can work with, what we can do. We all probably know people who have approached us and said, “Hey, I have this idea about this app or a site. Then they talk about the idea. We feel like, “Oh, it sounds kind of interesting,” and maybe you want to contribute in some way. Then we don’t have the time, or they wouldn’t -- I don’t know -- it’s just not financially interesting or anything like that.

Then, months later, we meet them again, and nothing has happened because they -- literally, I think we meet people like that that have great ideas, but they don’t have any idea where to start. They don’t know what to do. They don’t even know how to ask. Apparently, they ask us, and we should know, and we could probably do something if we have the time, the interest, and stuff. But, the point here is that we are actually in a situation to execute on that, and I think this is one of the greatest things about being in our field, like what a unique situation and position we’re in.

Then there’s complexity. At first, that might sound odd, right? It doesn’t exactly sound like something to be excited about. But, I believe it is because, actually, thinking about I used to work as a factory line worker at some point as a summer job. After day one or two, I didn’t need this belt anymore that other people were using for the screws and stuff. Not to say that I was so quick or something like that, but the work was so damn boring that I was adding excitement by--I don’t know--changing the ways I walked around the line and stuff like that in order to work on this. There were people working on this for 20 years. Then most of the students working there were already fed up with this after two hours. So, it was really interesting to see that.

We are certainly not in a field like that, but there is literally so much complexity that I think it challenges us in very interesting and very constructive and very useful ways. I actually believe we should accept these challenges. Sometimes we need people who are a bit fed up, like, “Oh, my gosh. Web development in the last 20 years changed so much.” All these things. Then they don’t feel motivated anymore, and they regret that things have changed the way they changed. I think we should accept that, and we can even feel excited about it.

Also, as a little story, in the early 2000s, I was working for a Java software company. I was the only in-house Web developer. I was working on the corporate side, and I worked on client sites. These were the days, the really dark days, where even Netscape 4 had to be considered, and there was IE5 and IE6. Nothing really worked, and compatibility issues and support issues. Still, had days where we had to tighten the grip on HTML because we all wanted to write this strict XHTML, and we wanted to use those hundred properties that we had in CSS. Now, we are approaching 400 or something like that, which really is not just linear growth. Things got really complex with CSS. I’m really torn on whether I should get started on that or not.

Audience: [Laughter]

Jens: Complexity: I was bored. I was like, okay. I approached one of the founders. I’m like, “Lars, I want to become a software developer.” That is actually one thing I wouldn’t say now.

Audience: [Laughter]

Jens: I wanted to be a software developer. He’s like, “Sure. We’ll pair you up with our programmers, and here are some things you can work on. Here’s a book,” and I started reading Bruce Eckel, Thinking in Java, and I’m not even sure how many Thinking in books he has written. I started doing that, and I was just lucky that I started reading other books. I started reading Steve Krug’s Don’t Make Me Think, and Nielsen’s Homepage Usability, and then Stanford University’s PJ Fogg’s book on persuasive technology, which is a really interesting book, still, about human/computer interaction.

I read Robert Bringhurst’s Elements of Typographic Style, and also a lot of books by Edward Tufte on information design. I can highly recommend Tufte, really, not just for our field as professionals but, in general, because we deal with information design in a lot of other places, of course, in the media and newspapers. There is an astonishing degree of problems, like with graphs and charts. They sometimes distort the information that we really get, and I think Tufte gives a nice, very pleasant access to this matter. It’s quite enjoyable to deal and to actually learn about this subject.

All the books that I listed, I think, most of us would have read one of those books if not more or all of them, so they’re really excellent books. I was just lucky that I ran into all this excellent literature. Yes, it’s not development stuff. But, I realized, “Wow, this isn’t boring. There is actually so much more to our field and it all relates to my and our work.”

For me, of course, back then it was this personal decision. Did I want to stay in Web development or do I want to get out of there? I stayed. It was that moment where I realized, no, this is not boring. There’s a lot of complexity, and this is really challenging. This is really interesting. This is really cool. I believe the excitement carries me through each day. Yeah? So, complexity.

Then, now, as we progress from how we get into our field to discovering and acquiring powers, to getting to appreciate the complexity of our field, then we see that we can also give back. I see two prime ways of giving back to the community and to the field. That is, one -- on the one hand, that is contributing to open source projects. Then, two, doing translation work. If I can get some hands again, who contributes or has contributed to open source projects? And, who here contributes with translations?

This is cool. I suspected that, on the translation end, we might be a few -- there might be fewer people. I think this is actually the really -- this is a very interesting piece because we are, and we are getting to, learn more about accessibility, I think, today. We are actually making content accessible. We are helping that more people can get access to, let’s hope, excellent information. Whenever we read an excellent article or whenever we read a super boring spec, we can go out, translate it, and make it available in our mother tongue or whatever we are capable of speaking. That is great.

Then, of course, we can -- so, apart from making that accessible and helping the field this way, helping the projects this way, of course, when we run our website, we host the content there. We sometimes get a nice kickback, too, just as this extra incentive if we then choose or if that’s important for us. On the other hand, for open source contributions, the only thing that I want to point out, probably, is that there is no change or no contribution that is too small. I believe it’s very important or it’s not necessary that we become full-time contributors to a project, but that small edits, like whether that’s fixing typos, improving code snippets, and so on, go a long way, actually, in contributing and helping other people in other projects.

For me personally, that means whenever I focus on a repository and I go over something, and I have routine checks and routine scripts go over my code base, and sometimes, say, they would compress images or something like that, I would play that back into the repository. I think these small things are absolutely legitimate and they help. So, it is not needed that we, say, become, like, yeah, again, like we invest a few hours every week in order to become really strong contributors and supporters of an open source project. This can be simple things and small things that we can contribute. I think this is pretty awesome about our field that we can actually do this so that we have this option to give back.

Then, as a fifth point that are a family of points, if you want, that I like to call out is also that option. We share this with other fields, of course, but it’s still a bit different for us. The option that we publish our ideas or commentary or our research, that we can do this. Again, another benefit when we run our own site, we can do this there. Then we can do this for magazines, and we can do this for publishers.

We have a great opportunity there or great possibilities there in order to, again, learn and grow through teaching, in a way, and then, also, to build a reputation this way. I find that’s unique. If not for the medium, because this is our medium, and there are probably more options and easier and simpler options for us to go out there and publish than it is for other fields. We have several advantages there.

With these things, I want to close this first part and move on to setting everything up on fire. The way I want to do this is actually not an analogous. I will not take the points that I made earlier and try to refute them or anything like that. What I’d rather like to do is take some, perhaps, different aspects.

One, for instance, practicing, and that is such a big topic, actually, because practice is really important for us. I hope you can agree on this. It’s important that we touch code. As developers, we need to be able to code. As designers, we should also be able to design something.

It’s clear to us that when someone registers a domain at DreamHost, does a one-click install of WordPress, goes to Squarespace and generates a logo, goes to Paletton and generates some colors, then goes back and downloads a theme and changes some colors, and updates the logo, that that’s not a developer nor a designer. Anyone can do that. Of course, what I’m referring to is an entry line of business that allows people to set up sites like that.

But, we have similar situations in other ways, in other aspects of our work because, if you want to really push it on the other extreme, as developers we just go and write our CSS, write some selectors, some declarations, we test, and then, well, off we go. Proprocess or linter, who cares? I am exaggerating, of course. But, if you think about it, then what is the difference, really? We leave everything that is related to the craft, really, to tools because anyone here -- not anyone here -- anyone outside, we could ask, “Hey, this is the basic syntax of a style sheet. How about you go and write something?”

The question sometimes is, is there a noticeable difference then? They might struggle a bit like finding the declarations that they need in order to do something. Of course, it will take some work. But, what is the difference really if, at the end of the day, at the end of our work, we leave everything else up to the tools, like cleaning it up, sorting it, like optimizing it in whatever fashion?

I do not want to say that our way of writing CSS, this way, is so wrong. And, I will not make suggestions here. But, it goes beyond that. We have other tools that do similar things for us. The trickiest thing is we want that, too. Not just because of convenience, but we actually go out there. This is a page of the Google book, well, at least where I picked it up, is whenever you see things being done repeatedly and you can automate them, then go and automate. For efficiency and productivity, that is really important.

There’s a conflict there. If we go and try to automate everything and try to use tools for everything, use scripts everywhere, then that has an impact on our craft. We need to be aware of this. That’s probably all I want to say here. This is one danger that we need to watch out for.

I’ve, at some point, pushed out this idea -- certainly not new, certainly not just coming from me -- this idea that we need to make our lives difficult at times. This is not something that any one of us can tell the other person because we need to be honest enough that we notice and see where we struggle, where we can’t do well enough, in order to then decide we don’t use tools for these things, but we understand the technology and we understand how to really do it ourselves.

For me, as an example, I like to focus. One of the areas that I like to focus on a lot is maintenance and maintainability. I intentionally -- I’m not a masochist, well, not -- sometimes, maybe -- but, for some projects, I don’t use a common management system, nor aesthetic site generator, or anything like that. I maintain it manually. I have one site, I think, very small, fortunately, thankfully, 38 languages, and I maintain it all by hand. This is painful, but it is painful in a good way because, when I notice that I fuck up, then, okay, I learned something. There’s not a script running in the background that compiles it. I just one piece where I change it.

Now, I intentionally made it a bit harder for myself so that I know when I screw something up that I feel the pain. There not a tool remedying, or that I never notice that I screwed up in the first place. Or, worse, in a team environment, that somebody else cleans up the stuff that I’ve done. This is an example for that, so where we intentionally make our lives more difficult, where we focus on practice, where we focus on actually really understanding and mastering our craft.

Also, the thing that I’ve not even alluded to, but you can see that clearly, I think, in the power camp, our industry and our field allow us to work alone. You can work freelance and self-employed, and you can even, as a consultant, I think, spend a lot of time alone. Then, worse, and I really don’t want to make this a topic here, but I think there are some problems around that.

Worse, we romanticize, and we glorify, this idea of the digital and the global nomad. You can just work anywhere. Just go to the Caribbean and handle your client projects. We say this is great. This is ideal. This is the ideal worker these days.

I’m exaggerating again just for the emphasis. But, there are problems to that. I’m not talking about what this really does with you, like whether it’s really that favorable and desirable to leave all your friends and family. But, the thing is, when we work along on stuff, and when we work alone on stuff for an extended period of time, there is a chance that we forego any kind of criticism and criticism in the sense of scrutiny, not in the sense of negative feedback; by all means, just scrutiny. We know that pair programming, peer reviews, code reviews are useful for that reason; just so that we have an eye on each other that we can check if there’s something that we can do better or if there’s something obviously wrong or something like that, up to the point where we outright escape reality.

That probably sounds -- fuck it. I don’t have a good example for that, but I guess you can really push it very far. And so, it’s something that we need to watch out for that when we work alone, this is an option that we have. It comes as a perk of our field. And, we will see at a later point then, too, how it is actually also very tempting to do that, but how it’s something we need to watch out for, that we need to guard ourselves against.

Then, the power, in general, and the sky having no limits. Actually, there I should probably say we obviously have touched on the point of choice where you can work alone and freelance, where you can hire with agencies or multinationals. You can try a lot of things in our field up to founding companies, and we see great examples for companies even in Web design and development. If I think about Jimdo in Germany, for instance, or Wix in the U.S., for instance, companies that of course target people who want to run websites, and we are in that business, and so I find these are interesting examples for companies that are successful. I think they actually have their ups and downs, but is examples for where we can push a very development and design-centric idea of our profession.

And so, what happens there is -- I don’t necessarily see that and observe that that much when it comes to career choices, that people are literally waiting for months to decide whether they want to work freelance or whether they want to work for a company. But, we see this, I think, in technology and tool choices, and then also when people, when we work on our own projects that we lose focus, that it is power that we can do anything that we actually do anything. That’s problematic, and with that comes with some sense of inertia, too, that sometimes we get slower because first we need to evaluate this and that and, maybe, how do we choose and things like that. They are effects of this.

Then, in the next aspect, the complexity of our field. Now we get to some drawbacks that it’s gotten really obscure now what’s right or wrong. In the technical wrong, as we know, there often is right or wrong. Sometimes there isn’t. There are a good number of questions, and I think we are then venturing more in design, usability, preferences, and so on. You want to have a right or wrong but, for some technical questions, you can clearly say something performs or works better than the other.

But, it’s gotten really, really difficult now to tell when that is the case. I would venture to say that this affects us as experts, as professionals just as much as anyone else, whether we’re junior or more expert or more senior. I think there are two reasons for that. One thing is something I think we all struggle with, in a way, and that is probably the simpler reason that it’s really hard to tell who is an expert.

How do we judge that? Is that the person that’s published something or worked for a company or has written this project? What is it? How do we tell whether a person really has a point somewhere? Maybe we find out we can’t really tell that because we can all make mistakes.

Of course, on the other side of the spectrum, there are good points that junior developers and junior members of our field do make. We sometimes get feedback from people who aren’t really long in our field, and they can make excellent remarks and point us to things that we have completely overlooked. So, the expertise thing is one thing.

The other thing, then, and I will try to not make this too academic because I don’t think that would help us that much, but there is a problem in the way we argue. I will give an example also out of a field or an area dear to me, and that’s frameworks development. You can probably imagine person A saying, “Hell, yes. Absolutely use a framework, always,” because you can quickly get something out of the ground. You can quickly work your project and quickly see whether this is working or not - proof of concept.

Then you get a person like me who says, “Oh, my gosh. Please do not use a framework because, sooner or later, you want to tailor a framework. An external framework can never know what you intend to do with your site, so it comes with too much code.” More often than not, it comes with too much code than too little because, obviously, you pick the stuff that covers your needs. But, it will always cover more than those, so it has bloat in there. Thus, it’s not efficient. Thus it, therefore, brings performance issues. There are also security problems with that. If you’re always continuously hooking up to third-party services or servers or something like that, you always need to watch for a third party.

Now, you have these two persons, and they tell you something contradictory. One says, “Don’t use them.” The other says, “Do use them.” Of course, we already see what’s the problem here because the premises and the goals are different. The person favoring and advocating frameworks and let it be something else, too, like it could be libraries or something like that. We’re saying, “Here. Speed of execution is important and proof of concept.” The other person says, “No, quality is important and security.” Premises are different.

The next thing there is we need to -- I guess this is fairly easy to follow, but it’s something that we need to keep in mind both as recipients when we follow arguments, and then also as the ones bringing them forth. When we write, we need to be clear. That is important that we make clear, yeah, the premises of our arguments, what we’re really after. Then we can still run into situations where you read five -- we get five different expert opinions and they are all different and they are all right.

Then you have other aspects where, of course, you have several people. They all give you some answers, and they’re all wrong. It’s just gotten difficult to tell. I think we need -- perhaps just need to acknowledge that it’s gotten really hard now, and that we stay careful when it comes to judging solutions and judging commentary and judging views because of exactly this situation. So, it’s important that we keep in mind that we argue properly and, I don’t think, since this is really something you can dive in academically where it’s about the logical construction of arguments, that this is probably not a problem that goes away that soon, not in the landscape that we’re in right now where we face that ton of complexity: the different technologies, the different tools, the different philosophies, the different approaches, the different mindsets, et cetera.

Then the fifth point I want to make here where we put everything on fire is that instant publishing, as nice as it is to get a kick out of publishing something on our website, the kick we get out of publishing an article for a magazine, the kick that we get from publishing our first book or the second or whatever. This is also something to guard against because, yes, we probably get some reviews then at later stages, seeming it must make some sense what we’re saying and what we’re doing. Yeah, there’s probably something useful in there. But, it is a problem, too, because we get this gratification. We get this kick. But, it is also a danger that it messes with us in a way that we think there is something more to our work, that we are somewhat special. This, I want to use to actually quickly jump to the next points where we tried to get ourselves out of this situation. I can already say, I don’t have five points again. Only three more, and they’re also not exact matches to what I’ve just described.

We’ve seen, I hope, that our field and our neighboring fields are really special. I think they really are. The thing is, we are not, and it’s funny because I do not want to make this a hobby psychologist thing. And, I don’t believe much in this idea that we say, “Oh,” and we are all special, and then we’re not again, or something like that, and then we get into some -- I don’t know where you end up then, where this is going when you start arguing this way.

Of course, we are valuable, and we are people and everything. But, our field gives us unique opportunities, very unique advantages, but it’s not that this makes like we’re special in the sense that we’re also entitled. I think entitlement, these days, is a really important thing to keep in mind. I need to caution myself now not to, again, get on this track of hobby psychology here. But, there are these indications and these ideas that whenever we look around in society, people for, actually, very -- for quite opposite reasons, actually, the people who are doing really, really well seem to feel really entitled about everything and need special treatment. Then we also have people who do really, really poorly, and they also feel entitled, and they also feel they need special treatment.

We have that, and I want to stop my commentary on that there because, “What do I know?” But, the thing is, it is something that I think affects us too. There are unique options and opportunities in our field, unique powers that come with it. Okay. Let’s just be grateful for this.

The other thing that I think we can look at more closely is focus. I want to start with a little story there. I picked up a book by Gary Keller last year. It’s called The One Thing. I think it’s also pretty popular. I read this book, and I’m like, “Ah, okay. Awesome. Focus.”

The idea is really like, you pick your work life and then your personal life, et cetera. Maybe also for your day, you pick your one thing that you want to focus on. The basic, the essence of the book is pretty simple. What does Jens do? I sit down and open up a spreadsheet. As a self-employed person working on my own stuff, I’m listing all the different things that I’m doing. I come up with this list of 50 items. I say, “Jens, okay, yeah, focus.” I was marking through and X-ing out the things that weren’t important or I found they’re not important. I ended up with a list of 45 items.

Audience: [Laughter]

Jens: That is not focus. It took me actually a major personal earthquake earlier this year where things were pretty shitty. I was like, “Eh, I don’t really work on stuff right now but, for some reason, I need to. I need to do some things.”

I was looking at the different things that I was doing and thinking about them, and also feeling a bit more like, “Where is my heart at?” because I was trying all sorts of shit and stuff, and projects here and there because, when you are self-employed and when you really look into making your living, and again we have these options, right? We can focus on the content side, affiliate marketing, the people making thousands of euros with that.

Why not do these test balloons? I was looking at it. It ended up with two or three things. I was like, okay, yeah, okay. But, I didn’t set out to get through a major crisis, but at least I’m focused now. And, I do not wish this to anyone else here that it’s necessary or I want to suggest that it’s important for us to go through any kind of crisis in order to get there. But, I do believe, and I strongly believe, that it is important for us to focus. That we are aware of where our priorities.

By the way, things get, of course, as always, they depend. They get more subtle. For instance, if you are junior developer, designer, or member of our field. It does make sense to try things, to cast a wider net. Try things. Don’t be too focused. Look at everything.

But, the ones who are most senior here, I think it is important that we focus, that we know what is really important, what are the projects we need to look at. What are the technologies you want to be really good at? What is it that really matters, and where is our heart at. I think this is really critical.

Then, lastly, this is an odd thing, too, and I will try to explain this just a little bit because we’ve already talked about working alone and stuff like that, and then also the options that we have in our field, like, do with us. For me, try to think whether this is such a useful start, but I’ll try it this way.

In my time at Google, and this is a high-performance environment, I never really struggled there. It’s not to say that I can do all these things that easily. No. The reason why I didn’t struggle -- and I only noticed this years later -- was that I had already carved out a niche. I have my specializations, and I suspect many of you do too. You specialize in something.

The interesting thing about specialization is, it’s actually a very smart way of evading, escaping competition because, when you are a specialist in something, and when you work in an environment where, evidently, you’re the only person doing this stuff, so it doesn’t mean that on the whole planet you’re the only person doing this, no, but suffice if in your company or in your team you’re the only person doing something, you’re a specialist, and it’s harder to compete against you.

What I’m trying to say is -- and I need to start another thread here -- there’s an excellent book by Alfie Kohn called No Contest, and not only does he argue that we as humans aren’t inherently competitive, but rather the opposite; we are cooperative. We get where we are, and we got where we are, through working together, through cooperating. I deem it actually a really terrible thing when we keep on telling ourselves these stories that we are all competitive and that we would eat ourselves alive and all that stuff. I think this is B.S. We are cooperative.

Now, when you look at it, if we assume that we are cooperative, and then another point Kohn makes, we are in an environment full of structural competition, as he calls it, where, in education, in the workplace, in society, you have all these circumstances that force you to compete with your fellow beings, humans, the English of liches menschen.

Audience: [Laughter]

Jens: That’s bad news. So, I mean, we all need to be better. We all get compared, judged, assessed, and so on. I think this is terrible. For me, it was funny because I know I’m taking on competition. I don’t mind competing. I don’t want to but, if somebody is pushing me, I compete. Then, I think the strategy is nice if you think about, yeah, you specialize, or you work alone on things and so on because, yeah, you’re competing in a way, but you’re also not. Then, as we’ve seen, some other issues come up because you isolate yourself in a professional level and so on. You have different issues then.

The point that I tried to make here is, just, let’s not fix the world here. I have no idea what we are supposed to do about structural competition in the workplace - no idea. That’s not much cup of tea, really. But, it is important for us, I think, to be aware of this and to look at it and figure out, like, okay. Well, maybe it affects us. At least acknowledge that.

Closing then, I want to, really with -- I want to do with the opening remarks and with what I’ve sprinkled in here and there that our field--Web development, design, and also the neighboring professions--are awesome. They’re fantabulous. It’s really fun. They are lots of great things about our fields. What we learn there, the opportunities that we have, like the growth paths that we see there, the many options, I think, are fantabulous. That’s all I want to really say now, and that’s why I’m personally also very excited now to see all the other talks and to be here at Beyond Tellerrand for today and tomorrow. Thank you.

[Applause]