Tree of knowledge, career choices and selective consistency. Today, we take a step back from our daily work to discuss the frontend landscape. Kuba speaks about chances and challenges of being a Senior Developer in 2016 and how he sees the ecosystem evolving in the near future.
Michał Nowak: Kuba, who are you and what do you do?
Jakub (Kuba) Strojewski: I build working apps that can be expanded.
What does the customer get as a result of your work?
We protect customers from themselves a little bit. They want stuff delivered asap, built in a quick & dirty manner. Without thinking a few months ahead. That's because they need to show something, sell something that at least seems to be working. Money becomes the driver. They sacrifice quality for profit. This is how business works. That's why developers should protect the products they build. Some choose to do it, some of them surrender.
You mentioned "long-term perspective". What does it mean in frontend?
What I call long-term quality of an app is not whether the app works for one, particular flow or path of functionality, but whether all the features will work in a month or a year. How much maintenance and extra work will all these paths require? As the app grows will changing it be expensive or not?
This seems to be a rare approach on the market. Why do you think apps aren't built this way most of the time?
I don't think it's specific to the IT industry. When you look around you'll find similar situations: in construction, furniture, utilities, etc. In the "real businesses". I discovered that it's hard to find poor bread in Paris. Perhaps the French put higher priority on the quality of their food?
And that's how it is with customers. There's the ones that want the good stuff, they plan development of their business in a long run and they need tools they can depend on. They are the ones that need something quickly. "We need a tool, so go make it." They don't know how it's done and they shouldn't need to know the details of the implementation.
What's unusual in your approach to work?
In Evojam, there's not much that distinguishes my approach from the rest of the team :) Everyone who works with us for some time get's hooked on this focus on quality. We have an allergy for duct tape solutions. We're not building software just to invoice the client. We want to do good craft. Like a decent quality watch for example, or good bread. For the pure satisfaction of knowing how to do it well. We also want to have the satisfaction of learning and honing our skills.
None of us wants to do unimportant, irrelevant things. We all seek satisfaction in our work. Work should provide at least one of two things: satisfaction and/or good pay. It's best when both of these things are there. If it provides neither of those it sucks big time. Our team members probably need both.
You mentioned quality, taste, craftsmanship...
Yeah. I like the word craftshmanship a lot. You can lay a floor by pouring concrete and just leaving it there. Or you can do it carefully, with a right approach that will make it durable. To avoid doing it over again after a short time.
This would mean the craftsman didn't care about that floor he was building, because he's not the one who will be using it.
Exactly, they don't care. He puts in the hours in exchange for the hourly wage. Others do their job carefully. With the future in mind. They want to make whatever they do usable, in many ways.
Until this point you haven't mentioned frontend...
Mhm... It's a specific part of programming where you see the effects of your work pretty quickly. That's what's drew me to the frontend. Nowadays I can work on app logic for 2 days without running it every few minutes to check whether it works. When I know what I'm doing I can build the structure, implement and review it before testing it. And it usually works :)
What are the pitfalls of the frontend world?
Well in the frontend community we sometimes discuss a technology, that becomes obsolete within 17 seconds. Do you know that someone calculated that there's a new project released on npm every 17 seconds!?
What ambition behind all this code!
Fortunately the changes in frameworks we use do bring new value: features or bug fixes. We strive to use bleeding edge technology, to use the most fresh versions of libraries. Sometimes it means we may not fully understand the intention of the author, patterns they've used... It's easier when we participate in creating those libraries [Kuba's referring to monet.js he contributes to]. But going back to your question I'd say that there was a few times when it took us a while to fully understand some approach. It resulted in a bit of nightmarish code that we had to untangle later.
Our assumption is that we need to keep learning and going further. This expands our knowledge and builds up experience. Imagine knowledge is a tree. Your level of knowledge is how high you've climbed. The horizon is the things you don't know. As you climb the tree of knowledge your awareness of your ignorance increases rapidly.
What role does experience play in all of this?
Experience means caution. Wide perspective for every problem - you see in broader context. You're able to process new problems though multiple points of view. This allows you to avoid some of the failures.
...and yet there's a new framework every 17 seconds...
That's why it's worth to use the latest and greatest tech. It not only brings the benefits of new features and fixes but it also makes production upgrades easier. Just because you've gone through those upgrades in the development phase, the app structure needs to account for changes. This way if it's properly maintained it doesn't become legacy code too quickly. It also makes them more secure along the way. On the other hand if you skip upgrades and need to do a big version update it can become a problem...
OK, so you've described a certain approach to building apps. Can you think of a project where this way of building them is a good fit?
First thing that comes to my mind is the uptime of 1-Page application we've built and maintained. Except for the network-caused downtime the platform worked with 100% uptime over 2+ years. Including backend and infrastructure.
From your vantage point how does the frontend world look like right now?
I see people running around dazzled by concepts that have existed for 30 years in computer science :) They just weren't visible to the developers that went shallow when learning the theory behind programming. Some of them remained at the level where they hooked up together a bunch of ready-to-go modules and shipped it. Just to make it seem like it's working.
Sometimes they discover things that have been used and tested decades ago and they're surprised you can do this stuff in JavaScript. With TypeScript and RxJS for example, static typing and streams become popular on the web. Dependency injection as well, although this one causes shivers on frontend developers' backs :) They make work easier, they make stuff more reliable, more secure.
Also functional programming starts to make its way to the frontend mainstream. React is an example of this functional approach. Frontend draws from the experiences of the Haskell community for example.
What are the benefits of this functional approach to frontend programming?
Ability to choose among various ways of building apps. You may choose to build code that's easy to reason about. You say what you want to happen rather than writing a detailed procedure that delineates each technical step. You abstract certain things to make the flow of reasoning easier.
Also some things are just easier to write using functional approach. The code can be more reliable and more readable. However this requires some learning and understanding of this approach.
You said it's easier to reason about apps written that way. How do you see that impacting bigger applications as they grow more complicated over time?
Yeah, one of the aspects of the functional approach is to split the application into small parts that have one, simple responsibility. Actually it's an implementation of the single responsibility principle (same as in object-oriented programming). Most of the interesting solutions tend to go this direction these days.
The counter-example is a junior frontend developer writing a 700-line long method imperatively detailing what needs to happen. Without splitting into independent pieces. Probability of making an error grows with the square of number of lines in my opinion. The risk increases as your monolithic piece of code grows.
So it's a simplification for our brains.
Yes and no. Because on one hand you make the code more clear and understandable on a high level but on the other hand you need to train your mind to be fluent in this functional approach. The good news is that it's a one-time effort to learn it. Then you can use it throughout other projects. Oppose that with the spaghetti-code way where you need to dig through the logic and the mess each time you want to make a change. You need to fight with the complexity over and over again.
You mentioned frontend devs don't dig deep in many cases. On the other hand you're self-taught programmer. Where do you learn from?
Let me first answer why I do it like that. Because I get bored easily. I love changes and learning. I like to get out of my comfort zone. I make it a habit. Also, whenever I look at code I think about ways of improving it. Perhaps it's perfectionism.
So is any of your code in production? [laughter]
Of course, plenty. After all you need to be pragmatic about improving the code. At some point you just ship it and move on. The next time I'll be implementing something similar I'll make it slightly better. You know, code is never finished...
Let's talk about music, which was your main profession for many years. Why did you switch from being a full-time bass player to a programmer?
Well it was about the money. Not necessarily the amount of it but the predictability of income. I just needed a reliable source of income. Living off of music made me take various jobs like lifting heavy objects or being a driver. At some point I realised I did 20+ different jobs.
Does music and all the other things you've done impact the way you code?
Surely. I guess my perspective is broader thanks to all the experiences. Being a driver for a disabled person and helping them to move around is not an easy job but gives you a different view of the world. It's hard to tell the impact of those experiences on coding.
The breadth of your vision, knowledge, the feeling of what you do makes you more considerate, more attuned to the work ahead of you. With time you develop an intuitive sense of what you do.
Just like with a historic bow where you have no aiming devices. There's no analytic way of learning to shoot it. You just practice and after a while the neural network in your brain adapts and starts to have a feel for where the arrow will go. This includes the muscles, posture and everything else. Your subconsciousness can take in a lot more information than your analytical brain and process it a lot faster. That's how you develop a skill. And this influences the way you approach programming. You develop reflexes and intuition. But only if you decide to go deeper and to practice.
Given the pace of changes, the deadlines in projects, is there time to actually learn deeply?
Well that's the reason why frontend discovers old concepts so late. You can learn about computer science on a deeper level, trying to understand the underlying patterns instead of chasing the latest framework. The details of the pattern implementation may change but the rules remain.
So what you're saying is that whether it takes the form of AngularJS or React doesn't really matter?
Nope, as long as it provides you the tools you need.
Let's talk about the frontend landscape. What interesting changes do you see ahead?
On one hand there is the languages that get transpiled (compiled) to JavaScript: TypeScript, Coffee Script, etc. On the sidelines appeared something like asm.js - a subset of JavaScript that is very optimal and fast. It goes to the point of being ugly, less readable but it's extremely fast. Someone even ported Quake 3 to Firefox browser and it was only 2x slower than the native version. That's amazing if you think about it!
And it's not the last word because there's also WebAssembly. They try to look deeper into the way JavaScript is being unpacked and executed in the browser. They aim to build something like JS-bytecode of sorts (similar to Java-bytecode) ready to read and execute by the browser.
Now if you connect all these developments it will allow building a lot bigger, more scalable in-browser applications. You get a thick client that performs as good as native, desktop application.
Haven't we been there with Java applets or Flash before?
Yeah, but it was adding an extra layer of plugins in the browser. And here we still operate within the browser, in the native runtime. However in order to build such apps one needs to learn a lot. This world is not accessible to the people that stopped on the simple stuff.
I remember a year ago or so, someone from the original Java creators said that JavaScript has achieved the things Java was designed for. So it's a language that runs in any environment. Including refrigerators and satellites.
Anyways the future of frontend is tightly connected to the development of JavaScript, which is already very popular and it's becoming more civilised and more manageable these days.
Let's talk about being a senior developer. What are the pros and cons of being in such a position?
Well, "with great power comes great responsibility". You influence people around you in a strong way. I need to be cautious when criticising bad practices I see in the community. Before doing so I have to first make sure we don't do those mistakes ourselves.
What about opportunities and threats of being in a position of a senior developer?
Chances are limitless :) Risks are almost non-existent in our profession. You mainly have opportunities and no risks. Perhaps it's just a temporary El Dorado, I don't know. My friend working in London told me that you can find a frontend job by bumping on someone on the street. And a good and well paying one. There's large (over)demand for frontend developers. Especially the good ones.
So such a developer can pick and choose among multiple options. How do you make that choice then?
Do what you want to do. Pick something and if you don't like it - change it. It's a weird situation.
How not to harm yourself in the process?
Well it's hard to say if it's a right choice before you start new job. You may land in a project with tons of crappy code and very little to learn.
I'd avoid all marketing agencies, media companies. All the frontend built for marketing purposes. Because even if the requirements and design are great, you get a week to implement it and you know you'll have to cut corners and build something quick & dirty. And you can only use stuff you know as there's no time for learning, no time to upgrade to the latest libraries.
This will stifle your learning and after a while you may end up in a bad place, having obsolete knowledge. That's why you need to be on the bleeding-edge of the tech.
You mentioned learning, progress, possibility to use modern technology, to fail sometimes. Are there any other things that matter at work?
A good boss is important as well. I once worked in a company where the boss of my boss was a complete ass and it impacted nearly all of the developers. It wasn't an environment allowing people to learn. I managed to set my boundaries but it was frustrating for others over there.
Also remember that a lot of your work, how you implement stuff depends on your surrounding and your context. On the culture of your team. There's usually tight margin for the level of quality accepted in a given project. So you need to be flexible, to adapt. Our team [at Evojam] consists of quality-nazis, however when there's a need to lower the standards in a project, we do it when we have to. We'll always push to make it slightly better within the acceptable limits. This way the customer and the team benefits.
You need to avoid frustration in your work and in your life. All the things I mentioned before may or may not induce frustration. You need to keep an eye on that as it can lower the quality of your life.
You always have millions of things you could do so it's possible to get frustrated by all the stuff you're not doing. How do you avoid that?
Yeah it's a challenge :) I'm always drawn to so many things. Some time ago I resolved to have only one hobby. I do regret all the ones I've neglected but at least I've made my choice. The shooting range is my place of relaxation.
But it will change in the future, I'm sure of it. I never say never or define anything definitively.Being consistent over the long run doesn't pay off. It's good to change your mind from time to time and to adapt. It makes life easier if you don't keep yourself attached to your old choices. People seem to stick to past decisions even if they didn't turn out to be good options. They do it just for the sake of being consistent. This makes no sense to me. It lowers the pressure.
One more thing helps me to choose from all the mess we have. The past we share as Poles. I remember times when it was very hard to get stuff. I had to build an aerograph airbrush on my own using parts from an old refrigerator. Now you go to a store and you buy one. The habit of fighting for what I want makes it easier for me to stick with a choice for a while. Long enough to go deep.
So what you practice is a "staged, selective consequence" - is that a good name for it?
Yeah, I suppose so.
Any parting comments or thoughts?
I'd like to rephrase the part about choices. Your choices aren't as important as you think because you don't know how the situation will unfold. For example joining a company is the only way to verify how it's like to work there. You may make a mistake, but then it's easy to correct one. Don't stay there if you don't like it.
Remember that you're operating in an employee market. You're in demand and companies need you to expand their business. Don't stress out about the job interview. It's not like you're being judged and graded like in school. I saw people in job interviews being stressed out, worrying about being rejected. They forget that the employer wants to hire them, they want you to provide the correct answer. Forget the way of learning you acquired in school. You're now learning to expand your knowledge and increase your chances for success.