Forem: Przemek Smyrdek

The Learning Funnel

Przemek Smyrdek — Wed, 31 Jul 2019 17:48:55 +0000

Thanks to all kinds of activities related to software development I’m involved in, from time to time I have a chance to talk to people entering this career path and listen to their struggles. One of the issues that occur the most often is caused by so-called ‘paradox of choice’ - a situation where the total number of choices one has to face (in terms of technology, programming language or the next best framework) makes it impossible to stay focused on the most important topic and learn efficiently.

Additionally, considering the fact that our industry is full of strong opinions (not always held that weakly) about growth and personal development, it’s pretty hard to define a list of tasks one should complete making a meaningful step towards becoming an even better software developer. Some people think that attending conferences is a waste of time, there are people who say that there’s nothing good this particular book, and of course, there are groups of people convincing you that the value this one tool brings to the table just can’t be denied.

Recently I’ve been trying to figure out a solution for both of these issues which could make it easier to find your own learning path in software development, and I think I’m finally ready to share my ideas with all of you. To be more specific, it’s time to learn more about the Layered Model of Learning Programming (the name is highly unstable).

The Key Question

Let me ask you a question - in how many ways could you start your own journey as a programmer? It’s pretty easy to define at least a dozen of them - there is an unlimited number of meetups, conferences, courses, books, articles, bootcamps, hackathons or pet projects you could get interested in to learn a bit more about this crazy world of software development.

One of the most popular ways to start such a journey I can think of is to sign up for a Computer Science class where you discover and play with languages like Python, Java or C++ for the first time. Some of us, however, decide to skip this step and would rather participate in bootcamps or other “task force groups” focused on intense courses for software developers. In parallel to those activities, an ambitious programmer can surround themselves with books written by industry experts, subscribe to their social media profiles where they share meaningful insights or maybe attend a few conferences to learn more about ‘the next big thing’. Finally, we start our first job where we finally have a chance to test all those theoretical concepts in real-life.

At this point, some of us may feel overwhelmed by the number of different paths one could follow. It is a well-known dilemma of most programmers that we wonder what’s the right order of tasks and activities to complete to become an expert?

Should I look for a job rather sooner than later? Is attending a conference a good idea, or a waste of time? Do I really need to buy this paid course if my current account balance is equal to zero? Is ‘Clean code’ a book worth reading for someone like me? What about this new framework that has been published recently - should I learn more about it? Based on my experience in mentoring programmers on various stages of their careers I can tell you that these questions are more popular than you think.

The biggest fallacy about learning software development is that for some of us it’s a one-dimensional path where the most important factor is the order of activities we are involved in.

It’s no wonder that such a model does not help us learn and grow without stress, maybe self-doubts or even anxiety. When the only thing that matters is the order of activities, all we think about is whether we should do this before that, or something else afterward? A book before a course? A talk before a bootcamp? A conference after a book? Is XYZ a waste of time? Is XYZ a good choice? And many more...

In general, there are these two questions worth answering to untangle the paths of learning programming:

What’s the right number of topics I should be interested in at this point in my career? Should I value a broad range of skills over very narrow specialization, or maybe the opposite?
How much time and effort I should invest in the topic I have in front of me? What’s the good balance between shallow and deep learning, and when to favor one over the other?

Today I’d like to show you my proposal for answering these questions.

The Next Dimension

There are two key goals for everyone who thinks about successful learning and developing their skills in programming:

build competitive advantage by being experienced and skillful more than the average in a small number of well-defined areas to bring the value for everyone who wants to work with you
stay aware of the situation on the market in terms of techniques, practices, frameworks, and languages to extend your ‘expiration date’ as a software developer and to be able to cooperate with experts from other domains

I believe you can easily agree with me on these two, but finding a good model to cover this concept is a more difficult task.

After spending long hours trying to figure out a stable learning framework based on these two points, I recalled something that all my friends from the world of marketing and sales use on a daily basis. The thing I’m talking about is called a sales funnel.

“A sales funnel is a visual metaphor for the path taken by a potential customer as he or she moves towards becoming a customer. Frequently used by sales and marketing organizations, the sales funnel helps companies understand and visualize their sales process and measure overall conversion success between each step of the funnel.

A sales funnel is shaped like an inverted pyramid, similar to real-world funnels, to which the metaphor alludes. The width of each part of the funnel reflects the audience size, with the top of the funnel being the widest and the bottom being the smallest.” ~ source

How does it relate to things we’re talking about in this article? Let me surprise you - in a very direct way! The only thing we need to do is to replace customers with topics we want to learn about and activities we want to be involved in:

Such a ‘layered learning funnel’ can be used by developers to manage the topics they learn about, invest time into them and interact with. The key point about this funnel is that it adds the next dimension to our thinking about learning and growing as a software developer by introducing this concept of level of involvement.

As it turns out, by noticing the difference between the order of things to learn and the level of involvement, we gain a pretty useful model of approaching basically every new concept without a need to limit your expertise in areas you're most familiar with.

To see how all of this works, let me explain the rules of this model.

It's all about layers

The concept I want to show you today consists of multiple layers (buckets) for everything that is (or may be) related to your growth - books, courses, talks, conferences, studies, papers, docs, frameworks, languages, etc.

Layers in the upper part of learning funnel may contain multiple topics you just "collect" to stay aware of how things work nowadays and what's the next big thing for your peers working in different areas of software development (languages you know less about, frameworks you didn't have a chance to work with, etc.). Layers in the lower part require much more effort but they help you build your expertise and market value.

The most important thing about all those layers is that the deeper you go, the smaller number of topics you bring with you (because there's a limited number of hours per day), but your level of involvement has to increase (because this is the place to focus and work deeply).

Let's go through each layer of this funnel to see how it works.

Awareness

This is the bucket for all kinds of activities for people interested in the world of software development no matter what language or technology or framework is being mentioned. The awareness layer is about attending conferences, talking to people at meetups, following social media profiles or just briefly reading some docs only to stay aware of everything that happens around you. Relatively low level of involvement, but a wide range of topics to cover.

Interest

There are some topics in the previous layer that may look especially interesting for you. For example, at one conference you listen to the talk about this brand new framework you have to check or maybe someone mentions this great language that BigCo uses daily, and you decide it's worth spending some time on it. You filter out some of the topics from the Awareness layer only to briefly check how does this new tool look from your own perspective.

Comparison

The Comparison layer contains all of the topics that fight really hard for your attention while being truly promising in terms of actual usage in real life. This is where you want to compare these shiny new toys with tools you use to build stuff every day. This is also the time to think about their weaknesses, bad parts, the context in which it should work or values that this specific framework, language or technology bring to the table. This is the layer that ends our dry analysis of a given subject because everything that comes next is mostly about practical application.

Evaluation

It's time to check how your topic of choice works in reality. For example, you can create a repository for a demo project where you're going to test this newly discovered practice or framework, you may introduce it in one of your pet projects, or even build an MVP based on it. The key thing is that on this stage the risk of introducing this brand new tool should be relatively low - all in all, you're only evaluating it without making any final decisions.

Action

Everything that lands in the Action layer can be immediately propagated to your portfolio, LinkedIn profile or your summary of expertise. The Action bucket is a place where we keep languages, techniques, and practices that help us build stable, reliable solutions where the amount of risk is minimized as much as possible. Topics we put in this bucket do not bring us the feeling of wasting time because they are directly related to our daily job, projects we work on and the reasons we get paid for.

Advocacy

The Advocacy layer is totally optional for most programmers, but the value it brings forces me to include it among others. So what's inside of it? Well, from time to time we discover something from these "actionable" buckets that makes us so excited, that we can't wait to share the news with our colleagues or the community we want to give back for. We start promoting it on the web, we talk about it at conferences, or we record a video explaining the basics of it. In some companies, we'd be called evangelists of this specific topic. Activities from this layer are very often super time-consuming but at the same time the return of investment from them pays off in a very meaningful way (building a personal brand, meeting experts and sharing knowledge with them, or even building a foundation for everything that comes next for you).

Show me how it works

My learning funnel, as a front-end developer working mostly with Angular projects, can look like this:

What's in my Awareness layer? Basically the whole world of software engineering. I'm really eager to learn about new languages, techniques or frameworks. I love to follow social media sh#tstorms about all kinds of stuff and debates whether or not the TDD is the right way of writing tests. I want to stay aware of things, I want to be prepared for changes that are possibly waiting for me in the future, and I want to discover new worlds without that much involvement.

In the layer of Interest, there are mostly topics related directly to my front-end experience. As of today, I'm following the development of Svelte framework, I'm curious how it will change the way we write our client-side solutions and I can't wait to spend more time on this topic. The same with Nest, which seems to be a really promising replacement for raw Node.js environment.

Comparison? Of course two out of "the big three" - Vue and React. Even though I spend most of my professional time in front of Angular, I'm a big passionate of new ideas released under both green-ish and blue-ish logotypes. I read about hooks, I read about single-file components, and I'm trying to borrow some of those ideas to the world I'm the most familiar with, which is Angular.

The Evaluation layer is currently all about Stencil and Web Components. I've managed to release a few production-grade projects based on these two and I'm constantly looking for more knowledge from those areas. Some time ago I fell in love with the idea of building truly reusable components which can be injected into your favorite front-end technology, and by that time I had a chance to not only build WC-based solutions but also discuss different ideas and issues with Stencil's core team and other advocates for that wave.

Moving to Action layer now, where most of the time I build stuff using Angular (and generally speaking, JavaScript itself). This is the framework I feel most comfortable with, so far it helped me build a few dozen projects so it's natural that I put a lot of attention on this part of my professional life. Additionally, as a big fan of solving things from first principles, I try to level up in raw JavaScript which saved my life more often than you can think of.

Last but not least, there's this Advocacy layer and due to me being a big promotor of the knowledge sharing movement, today you can read this article, watch my videos on YouTube or listen to a talk on a local conference. The total amount of time I invest in these areas is pretty big, and so is the outcome I feel every day.

In your case, all these layers I've just described will probably include a totally different set of activities. If reading a technical book is something thanks to which you build your awareness, surely it will land in a different bucket than in my case. If your daily job gives you lots of space to experiment with different libraries and frameworks, you will also treat these "risk-related" activities differently. All in all, it's not about finding the one and only way of labeling such activities as "reading a book" or "attending a conference", but rather about learning in this two-dimensional funnel where next to the order of tasks we also think about the right level of involvement.

Does it really bring any value for you?

Yes, of course, it does. Thanks to modeling my own way of learning the craft of software development everything I do has a much better structure, is organized in a better way and just let me work on my own skills more consciously.

For example, thanks to splitting different activities I'm involved in into layers, I do not feel guilty after visiting one or two conferences (for me it's an Awareness layer) only because some say it's a waste of time. On one hand, I understand that it's a great way of keeping my finger on the programming pulse and stay in touch with bleeding-edge ideas, techniques or frameworks, and on the other hand, I'm not really that sad after missing one or two events because it won't ruin my career immediately. At the same time, as we go into lower parts of the funnel, I know that there's a need to work on a pretty limited number of topics in a more focused and deep manner because without clearly defined areas of expertise I don't feel as comfortable as I'd like to.

Thanks to this additional dimension (level of involvement) I can approach different activities more consciously and expect different outcomes without being disappointed due to lack of results. The more I get familiar with something (an idea, a framework, a tool) and the more promising it looks, the more attention I put on learning it and promoting it to latter layers of my funnel.

Additionally, the model I explained here is not a tool that only beginners can include in their workflow, but it's something that anyone who tries to navigate their career path can use on a daily basis. At the end the process of learning a thing is endless, so I can't think about any reason why putting more order into it will get you into trouble. Give it five minutes and share your feedback with me - I'm really curious what's your view on this topic!

The signs of maturity

Przemek Smyrdek — Thu, 23 May 2019 17:07:36 +0000

I've been working in software engineering for more than five years.

Probably I should not call myself 'junior developer' anymore, but using the word 'senior' is also not that obvious in some cases. I would say that I'm right in the middle of a transition process.

Due to the fact that I'm not that far from being labeled as 'junior', and also not super comfortable with a word 'senior' (especially when sitting next to my colleagues), I decided to write a few words about the most meaningful changes in my own understanding the position of software developer.

Some of the points can be considered a bit harsh, some of them are more obvious, but all in all - I strongly believe in their value. Without further due, the list is as follows...

Being aware you know less than you think you know

You were one of the best students in your class. You graduated from a well-renowned college. People consider you a smart one. You found your first job very quickly and your confidence went through the roof.

Suddenly, during the first week of your professional career, you discovered, that there are people smarter than you. You discovered that the topic you were so deep into, is actually much deeper than it seemed months ago. You discovered that the amount of resources you should probably get familiar with is just hard to imagine. You discovered that some people find the topics you struggle with not challenging enough.

And… all the doubts hit you unexpectedly and your self-confidence sinks down.

You may ask yourself - Am I even able to do this job properly?

The truth is, there’s nothing exceptional about your feelings. Additionally, it’s not that bad with your knowledge!

It’s worth for you to know that the path you are following right now has been described 20 years ago, thanks to two social psychologists - David Dunning and Justin Kruger - who were trying to investigate the correlation between self-confidence and the actual knowledge in a given domain.

The conclusion from their research (The Dunning–Kruger Effect: On Being Ignorant of One's Own Ignorance) was that people with “deficits in their knowledge” tend to overestimate their cognitive abilities but those who actually understand how things work under the hood are more likely to doubt in their skills.

So, for you, the moment you become more self-aware and notice that you know less than you think you know is actually a blessing! It simply means that you’ve already reached the “Mt. Stupid” and now it’s time to slowly get better.

Finding the value in saying "I don't know"

After joining the industry dominated by knowledge workers, you may think that saying "I don't know" paints you in a negative light in front of others. You may think that such a strong statement proves how incompetent you are, making you irrelevant for your current employer.

As a junior developer, you may think that even the dumbest answer is better than no answer at all. "I don't know" means that you've failed. You haven't been prepared enough, you haven't read enough books, you haven't gathered enough knowledge from TED talks, you haven't paid enough attention while studying this topic.

That's the way in which the external world works. It’s obvious that it will work in the same way for developers, right? Do you know the pressure I’m talking about?

Except... it doesn’t. It doesn’t work in the same way because the devil is always in the details. Sure, there are cases where these three words can hurt your reputation (being not prepared for an important meeting, being not prepared for a knowledge sharing session, being not prepared for a debate about the topic you care about, etc.), but in reality, there is a long list of exceptions from this rule.

One of the examples I can think about is when "I don't know" helps the team save time on following the paths one is not so sure about. Imagine a meeting where its participants are standing in front of a very important decision that may have a huge impact on the project's future and you are being asked about some details regarding the technology you all want to use. You are not sure whether or not the answer you’re about to give is totally valid, so you have the choice now - either you can immediately ask for more time to double-check everything, or you can pretend that everything is fine and we can move on.

By picking the first option, the team is immediately able to create an action point from the meeting - “John will investigate XYZ and will give us the answer regarding...”. By picking the second option, the team operates under a false assumption that sooner or later will turn against them and will force them to rewrite a meaningful part of the system in no time.

Mature teams will definitely appreciate those who can admit that “they don’t know” because too often they have faced a situation where being partially sure made it worse in a very expensive way (in the context of both time and money).

Gettings used to the lack of perfection

On the beginning of my programming journey, my head was full of patterns and practices that in theory should help you avoid the 'legacy code trap'. It seemed so simple - when you do this and that your codebase is well-written and maintainable, but when you do something else, things go south. That's what the experts say, right? As a result of this kind of black and white thinking, every time I noticed the code that was not following the guide, I was immediately judging either the author, the project, or both.

As I started to gain more experience, I noticed that most of the projects I'm contributing to have exactly the same flaws. It seemed so weird! It shouldn't look like that remembering that there's this huge pile of books that should solve all those issues!

I was so naive.

There are plenty of real-life reasons like working under high pressure, deadlines, rotation in teams, switching managers, lack of motivation, or maybe project handovers that can have a negative impact on the quality of the code you're just reading. Sure, managers should do their best to help teams avoid all of that, but sometimes it's just impossible (sometimes there are no managers at all) and you end up with the code of quality lower than expected. It’s no wonder that from time to time you’re going to face code smells here and there because it just means that some work has taken place over there.

Let’s also remember that sometimes - what's even more interesting - avoiding perfection is a completely valid way of doing things!

For example, when there's a race between you and your competitors and the only way to finish first is to take some shortcuts and ship something which is 'good enough' you should postpone shipping the Mona Lisa of software development. Otherwise, in the future, there might be no projects you can contribute to at all.

I strongly believe that instead of an endless strive for perfection sometimes we should just chill out and avoid judging, stay more empathetic for those who maintained the code before us and stay focused on the more important things. Also, the boy scout rule applies here.

Being able to balance between needs and wants

One of the biggest challenges that each of us has to face at some point is about mastering, or at least leveling up in the art of time management, because the more experience you gain and the more trust others have towards you, the more time you have to make your own decisions during the workday.

The question is - what do you spend the time currency on? Do you follow the path of real-life needs or personal wants?

As a front-end developer, I’m facing this challenge nearly every day, because working in this position means that you have a pretty good chance to discover another amazing-framework.js that is meant to solve problems that are yet to come in your professional life.

I see a lot of tools that could change the way in which I build projects and presumably make me happier and more efficient only by switching from “boring-but-working.js” to “fancy-but-experimental.js”. From time to time I’m really considering it because it’s so tempting, however, for most of the time, I prefer not doing so.

Over time I learned that it’s just how things work in this industry. Developers who want to avoid being labeled as the “cost center” should really aim to prioritize the needs of those whose problems we’re trying to solve higher than their own technical challenges and framework replacements.

Such a harsh truth, right?

Keep in mind that I’m not denying the value of technical roadmap at all! For sure there are strategic technical challenges which you need to solve from time to time to move forward, but… I would really encourage you to think more often about whether or not your project solves real problems and what are the everyday struggles of its users.

All in all, it’s about the right balance.

Agreeing on the fact that sometimes the juice isn't worth the squeeze

Being a young, energetic developer is a really amazing feeling. You have time for everything, new tasks come and go every day, every single minute you learn a lot of new things, so obviously you’d like to be involved in as many projects and opportunities as possible. You want to prove to everyone that there are no tasks that could break your passion and willingness to achieve new peaks in your career. We’ve all been there!

And then, on one sunny day, your mentor says ‘let’s close this task - it’s not worth it’.

Wait - what? How could you say that it’s not worth it?! I have time, energy, passion and also some bits of knowledge to resolve that issue! I can do it! Let me work on that!

As it turns out, sometimes the juice isn’t worth the squeeze.

Experienced developers have this extremely valuable skill of executing a cost-benefit analysis regarding each task that’s standing in front of them and just abandoning some of them. For juniors, though, it may be a little bit of surprise.

So why the heck one would like to abandon the task which is enqueued in the backlog?

There may be plenty of reasons for doing so:

your team is short on resources so naturally, some tasks will be abandoned or at least postponed (which, in reality, means the same) down the road
by the time you tackled the challenge, the world around you changed and now it doesn’t make any sense to pursue it (market changes, customer relationship changes, etc.)
although people around you agree upon the importance of solving the task you are thinking about, it may be solved in a completely different way (sometimes in a purely non-technical way)

In general, I could say that it’s all about priorities. The more experience you gain, the more opportunities you see in front of you, so it’s pretty similar to the previous point. It’s not only about whether or not you spend your time consciously and accordingly to real needs, but also if you spend the time doing the right things at all.

Web Components Q&A

Przemek Smyrdek — Fri, 12 Apr 2019 17:53:26 +0000

Recently I've been involved in multiple discussions around Web Components and I noticed that there are questions that still introduce a lot of confusion among front-end developers. By creating this post I'm trying to summarize my point of view on this very important topic of the modern web.

Q: Do I really need them?

Let’s be honest - if you’re interested in Web Components only because of the article you’ve just read, or the talk you’ve just watched the answer is probably - no, not immediately. There’s no need to abandon frameworks you’re familiar with only to introduce yet another API into the thing you’re building. If the codebase you work with is rather consistent, or if there’s no need to extract framework-agnostic components and maybe the projects you create have a relatively short expiration date I would suggest sticking to solutions you’re most experienced with. On the other hand, if you work inside of divergent environment where different apps are based on different frameworks, where you can find some bits of legacy code here and there, and when there’s a real need for refactoring towards component-based architecture - yes, in such cases I would consider Web Components. At SmartRecruiters we decided to follow this path to unify multiple implementations of exactly the same feature, which resulted in an encapsulated component that can be used within both Angular and non-Angular apps at the same time (we’re Angular-heavy company). It helped us reduce the technical debt and overall complexity of components related to the domain we work with, without forcing to support Angular runtime everywhere. And we’re still on the very beginning of our Web Components adventure - more lessons are yet to come.

Q: I see the benefit of going Web Components, but why their API is so raw making it hard to sell to my team?

The reason why Web Components’ API looks as raw as you may be thinking about it is that they play a really low-level role in your tech stack. If there would be an opinionated way of handling data-binding, templating, state management or anything like that inside of Web Components spec it would close the doors for any 3rd party solutions that can be built on top of it. Confusion may also happen when you compare them to frameworks you work with every day, but in my opinion, the frame you should use when thinking about Web Components should be more like “a replacement for div and span” instead of “a replacement for React or Angular”. To help you understand this perspective I suggest you the following exercise - take some time to build this kind of raw “Web Component” and over time introduce improvements for different parts of it. For rendering mechanism, start from binding strings to innerHTML property, then move to template tag, then introduce dynamic templates using lit-html. For data binding, start from watching attributes and properties, then re-render everything manually in property setters and then extract this common logic of observable property to a decorator. By doing all of this you may notice how many ways of implementing the same thing (but better) you have, making you feel that you’re working with the internals of a framework, instead of a framework itself. When it comes to APIs that are easier to sell to your team I’d suggest checking solutions like stencil or lit-element.

Q: What’s the difference between raw Web Components and tools like Stencil or lit-element?

The most important difference between raw Web Components and all kinds of “Web Component factories” is about fancy named “Developer Experience” - the total sum of feelings you face when working with, and distributing Web Components ;) For example, in Stencil, you’re able to write your components using TypeScript. You are ready to distribute components in a form of npm packages via so-called “collections”. You are ready to put your components in front of IE11, because of polyfills management Stencil gives you. You can lazy-load your components and split the final bundle into chunks, and you can use JSX to build templates of your components. Additionally, you can save some time by using Stencil’s decorators like @Component, @prop or @State to get rid of duplicated logic not exactly related to the business case you’re trying to solve (by logic I mean things like registering your custom elements in the registry, reacting to changes of properties and attributes and re-rendering everything when the state is being updated). Yet, the most important part about Stencil (or Stencil-like solutions) is to be able to produce native custom elements that can interoperate with most frameworks you can think of.

Q: I know that tools like Stencil or lit-element improve the DX of Web Components, but isn’t it the same as using yet another framework? Is there any difference between these two approaches?

Let's think about the case where the vendor (Stencil, React, Angular, etc.) behind the component you built some time ago is starting to look like a legacy one. People moved to a different tool or the support for it has been suspended. Consider two possible scenarios. First - when there's a component that only works within a specific runtime (and most frameworks have their own very specific runtimes) that's basically it when it comes to interoperability. There's this very little chance that “the next big thing” will be willing to talk to a component built using Angular, React or Vue. They will probably introduce their own runtimes which might be incompatible with your component so passing the data into them becomes impossible. Now think about the scenario when instead of producing framework-specific components, your codebase is full of custom elements which meet these two requirements - you can bind data to their properties just as you’d do it with regular DOM elements and they react to changes of bound data, and you can also subscribe to events they emit via native “addEventListener” method. The first scenario is when you go frameworks which are very often incompatible with each other. The second scenario is when you go Web Components, which ensures that components you produce have a much longer expiration date. Answering the original question - yes, in terms of API it’s really up to your preferences, however, in terms of the outcome of your work, the difference is really meaningful.

Q: I decided to go framework-less for some parts of my project, but how can I handle application-wide state management inside of my custom elements?

When you look really closely, it turns out that inside of libraries like redux or mobX there is nothing about either React or Angular. You should think about them as regular JavaScript modules which can be combined with various components your app contains (yes, also Web Components), instead of tools that are tailored for any specific framework. As long as your component is able to subscribe to changes inside of a given store or state container, everything should work fine. To understand it better, you can create your own store or any pub/sub container as a vanilla JS module, expose it globally and call its methods from the inside of custom element you are building. Then you’re just one step from replacing it with your favorite state-management library and nothing really changes. In a broader context, this is still valid answer for other questions like “How can I … with Web Components” - as long as the relationship between different parts of your client-side codebase is set up properly and there’s no requirement for any specific runtime provided by a framework, things will just work.

To see the slides from my recent talk about Web Components click here - your feedback is more than welcomed!

Check out the tools I mentioned above:

Stencil - https://stenciljs.com/

lit-element - https://lit-element.polymer-project.org/

Applying CQRS to product design

Przemek Smyrdek — Sat, 02 Mar 2019 08:10:52 +0000

Do you know what the CQRS is? Command Query Responsibility Segregation is an architectural pattern used heavily in all kinds of back-end systems, which basically tells you that commands (mutations of the state) should be separated from the queries (parts where you read the data, i.e. for the purpose of UI or reporting).

There are multiple reasons why engineers apply this pattern to their projects, but these two are probably worth mentioning the most:

Firstly, CQRS fits well into this concept of so-called “Single Responsibility Principle” — one of the fundamentals of software engineering. SRP is all about creating things that do just one thing — no mixed concerns, no phone calls while driving, just one thing at a time. By applying CQRS pattern into your system, as a side effect, you are following the SRP rule — you can keep the codebase cleaner, make the maintenance easier, and let reason about a given part of the project without any hassle.

Secondly, CQRS helps you organize your system in a totally different way for the purpose of reads and writes. For example, there may be modules on top of which users run tons of reports every day, so the “read parts” of them have to be as performant as possible. By splitting queries from commands you can be focused on polishing just one thing (reporting queries) at a given point in time, so there’s less risk that other parts will break by mistake.

Software engineers know most of the benefits that CQRS bring to the table, so maybe we could borrow the same concept to a bit different domain — let’s say — design?

Commands or queries? Reads or writes?

Multiple times in my life I’ve seen (or even built) interfaces that are trying to achieve too many things at once. Imagine the profile page of your favorite social media platform — there’s a non-zero chance that somewhere next to your name there’s this “Edit profile” button that turns labels into forms and inputs you can interact with to update your profile data:

Sure, in some cases this type of UI/UX lets you complete the task of updating your data relatively fast, but it ruins both read and write experience. Why?
Imagine that there would be some kind of a source of knowledge where readability is a priority. The priority for you would be to make it easy for the consumers to gather most of the knowledge from this mysterious thing in the most efficient way, so you would have to spend lots of time on setting up all the margins and padding properly, picking the right font size, font type and maybe a letter spacing. We could say that “read mode” would be the most important feature of this mysterious thing.

Actually, it’s not that mysterious — it’s called a book. For books and other sources of written knowledge readability is a must have.

Now imagine that you are applying the same UI patterns of the tool that helped you to write a book (like MS Word), to the book itself. Instead of nice spacing between the lines, pretty fonts and useful margins you’d need to introduce completely different experience to find a room for all the buttons, labels, actions, notifications and scrollbars. MS Word is primarily about getting the writers' job done, not about making the readers' life easier (that’s the role of DTP).

For sure this is not the kind of book we would recommend to our friends, right?

Do one thing well

So this is where CQRS-like pattern comes into action in the context of design. For software engineers, separating reads from writes helps in creating systems that are easier to reason about and easier to tune up. For designers, the approach which is conceptually very similar helps in creating experiences that your users appreciate and
understand.

The example that came to my mind when I started thinking about it was Wordpress. Wordpress, as a platform, contains hundreds of thousands of layouts that improve the look, feeling and readability of the content you create. The same Wordpress contains just one text editor that has nothing to do with the layout of your blog, yet it helps you create the content that empowers it. Uploading the new layout does not break the editor. Updating the editor does not break the layout. As simple as that.

Do you see why the case I previously mentioned (inline data editing) breaks the read/write separation?

If we want to find a room for both read-only data, and data editors, we need to sacrifice one of these two — readability, or robustness.
If we want to let people execute two actions using the same part of UI, we may either complicate the workflow of gathering the data, or limit the one of uploading / writing it to the system
If someone has to actually implement this kind of UI, it may be hard to distinguish components that present the data from ones that modify it.

Knowing all of this, how could we solve the case of editing the profile data? One of the simpler examples would be to create a dedicated page where all the forms and inputs would serve solely to the purpose of “edit workflow”.

Relatively small margins and padding, call to actions that are easy to understand, dedicated loading indicators, empty states, and so on. No limitations from the perspective of profile page UI, no limitations from the perspective of where this data is being presented, etc. Pure editing experience. Commands, instead of queries.

A huge benefit you could gain from this approach would be in getting rid of all the constraints of presenting the data in read-only mode. No “I need to find a room for edit form”, no “How to hide these inputs next to the labels”, no “The font is too big for editing the data”. Feel free to introduce a bit bigger letter spacing, bigger font size, and fancy margins. No edit forms attached. Think about queries, instead of writes.
—
So that’s how I see it. As an engineer, from time to time I was trying to learn more about the CQRS pattern and all those positives it brings when applied.

Recently I found the connection between the same idea and the world of product design and today I’m trying to share this with you. Of course, it’s not “one fits all” solution, and there will be cases where inline edit forms work better than the solution presented here, but I hope that my post may help you reconsider or balance some of the design decisions you make during your regular workday.

I’m really eager to see your point of view on this. Do you find such a perspective useful? Do you think that inline editing provides a better experience for the user? Let me know in the comments!

Three myths about software development, busted by experience growth

Przemek Smyrdek — Sun, 27 Jan 2019 11:56:32 +0000

Let me ask you a question — what are the most important traits of successful software developer? Experienced person would probably say “-It depends”. That’s true, all of this depends on our work and life experience. Back in time, when I was was on the beginning of my adventure with software development, I would say that successful people have to know everything, they are working in a “one man army” mode, and they can solve every single problem you’re putting in front of them. Damn… I wasn’t even close to the right answer.

It’s not about knowing all the things

Knowing all the things is one of the most popular myths about people which should be considered successful. During first days of my adventure with software development all those books, tutorials and guidelines were making me stressful. ‘It looks like successful developers eat all of that during their career’ — that was pretty obvious for me. Does it really mean that successful developers are experts in multiple programming languages, deeply understand all the patterns and practices, were participating in all kinds of projects, and have opinion about everything? For sure there are people who meet all these requirements, but is this a rule?

I don’t think so. I had a chance to work with companies of multiple kinds — startups, software houses, outsourcing companies— and none of those places was hiring a person like the one described above. Does it mean they were not interested in hiring an experts? Of course not! But their definition of expert was very different from a person who knows everything. So how does it look like?

Very often we’re calling someone “an expert” because they developed their skills in a “T-shaped” way. There’s one, very specific area of software development where such person is considered specialist, and there is a broad range of topics about which they know the most important, up-to-date facts. Instead of brand and logos of the most popular frameworks, people considered experts are thinking about common practices and solutions not dependent on specific programming language or technology. Such distribution of skills help them switch technological contexts very quickly, and think in more abstract way then less experienced colleagues. Speaking about colleagues, experts cannot ignore those with less experience — that’s why they’re able to discuss various topics with people from different departments, working on a completely different layers across the org. Experts definitely can into communication.

So what’s the rule here? Instead of knowing all the things, I would say that experts know one thing very well, while everything else stays in their area of interests.

As simple as that.

It’s not a single player game

If you think that software development is a single player game… well, you may need to rethink that. But okay — it’s pretty easy to find an origin of such belief.

It’s natural for us to explain unknown activities through parallels like movies about superheroes or soldiers on a battlefield. Very often Hollywood gives us this example of “xyz-man” possessing a superpower thanks to which world is being saved once again. We don’t really understand the mechanics of superhero’s powers, but we know that the villain will be defeated on the end of a movie. Some of us think that developers possess the same superpower thanks to which they’re able to solve problems of every kind on their own.

There are two main problems with such view. First, “external branding” of our job is full of false assumptions. Second, it can cause lots of internal issues for developers who feel they’re not good enough to handle problems like main characters of Hollywood blockbusters.

The truth is, experienced developers can easily say “I don’t know” without worrying that such statement could hurt their reputation.

I don’t know how to solve this problem, it’s the first time I see something like that. Can you look at it and try to help me?

I don’t know how to solve this problem, because that’s not the part of the system I’m familiar with. Could you help me understand it?

I don’t know if every corner case has been covered by my idea — could we try to solve and discover this incrementally?

Saying “I don’t know” and inviting other people to help you is often considered as one of the most important skills of successful software developers. That’s right — by saying that you need help you’re proving that there are more important things that your own ego — for example, successful delivery of this crucial project you’re currently involved into. Well-executed teamwork can reduce the time spent on fixing given issue, it may also help in distributing the knowledge more equally across the team, and this can result in saving meaningful amount of money for stakeholders.

We’re playing a multi-player game, and there’s nothing wrong with saying “I don’t know”.

Not everything is worth your attention

Two very common myths covered — successful developers don’t need to know all the things, and they’re not operating in a “one man army” mode. Third case is even more interesting — it’s about ignoring things which are not worth your attention. Sounds arrogant, isn’t it? Don’t worry — it really makes sense.

How is this possible that for some developers there’s always enough time to tick most of the items from their “todo lists”, and for others it’s undoable? For sure we can all agree, that so called “lack of time” is one of the most common issues of people around us, but is it really about lack of time? Aren’t we all equipped with the same 8-hour workday?

The solution for the “lack of time” problem is called “well-defined priorities”.

That’s it. Without the list of priorities, everything has the same importance. That’s the issue knowledge workers are struggling with constantly — I have some knowledge, I’m able to do various things, but what should I do next? Maybe I should do as many things as possible? Maybe I should answer every single e-mail because it helps me gaining the reputation in the company? Maybe I should work on every single ticket in our backlog without the need to set things in order based on our priorities? No, that’s not the way how experts operate.

Do you know the “Pareto principle”? It’s an observation saying that 80% of the outcome comes from 20% of the causes. For example, 80% of company’s profits come from 20% of its clients. 80% of sales is happening thanks to 20% of sales people. 80% of the most important issues is solved by 20% of employees, etc.

How to translate this rule for the context of programming? Well, think about it in this way — knowing the fact that we’re operating under time, budget and goals pressure, try to figure out this one thing which could push your project forward by 80%. Which core area of the application you’re working with could be improved bringing the most value for the users? Which task you could be tackling next is the most important one from the perspective of overall success of the project? Are there tasks which could be deferred, delegated to someone else or even abandoned?

Time is precious, so use it in the most effective way. That’s what successful developers do whenever they can.

Few years ago myths I mentioned here was taken for granted. It was obvious for me that I have to know the answer to every single question related to programming — otherwise people will treat me as a mediocre developer. The same thing with not knowing things, admitting that fact, or inviting other people to help me.

Was that a healthy point of view? Of course not. Is our environment really working in that way? Thankfully not! Thanks to growing experience I started noticing how far were my expectations from reality.

Sundar Pichai, Google CEO, once said that the velocity of development of IT industry, when comparing to our own pace of changes, makes him worried. It’s hard to say whether we will be able to develop ourselves at the same speed as GPUs, hardware and AI-related technologies, but definitely we should try to be as flexible as possible. Under market conditions changing so rapidly, our own values and beliefs should evolve over the time, and there’s nothing wrong about it. Some time ago we decided to work in an agile environments, so we cannot forget that agility is also related to ourselves.

Is it worth to share the knowledge?

Przemek Smyrdek — Sat, 26 Jan 2019 15:55:45 +0000

One of the most important duties of knowledge workers is to share their own knowledge with the community. Some of you may agree with this statement, but others will ask — why does it really matter?

Today I’d like you to give you some example values that knowledge sharing brings to the table when it’s a part of your daily routine.

The more you share, the more you grow

Knowledge sharing may be realized through many different forms. Some of us write blog posts, others write longer articles, produce video courses or just contribute to open source documentation. In all of that one thing is getting better and better as the days go by — it’s the ability to teach other people. Is it really that important skill? Well, there are many side-effects of becoming a better teacher. Once you get better at teaching, probably skills like communication, empathy, listening to other people or creative thinking grow together with you. Very soon you can notice how people around you appreciate that you became a better listener or better communicator. By sharing the knowledge, subconsciously you’re making your daily life better.

Running the extra mile

Knowledge sharing is one of the multiple forms of mastering your personal brand. Does it really matter that much? Well, imagine a situation where your future employer receives ten resumes and out of ten people you’re the only one who decided to give back to the community by running a blog about software development. Spreading the knowledge tells the world that not only you’re active in social media, but you ran this extra mile to learn more, read more and know more. That’s how you can make a difference in a positive way.

Pushing things forward

There are no industries based on knowledge workers where something grew without the knowledge being shared first. We build faster and safer cars based on the experience of our teachers, we discover new animal species thanks to the experience of those who shared their own knowledge before, and we can help other people by looking at failures of the past. Knowledge sharing helps us incrementally become better and better, only due to the fact that someone written down their experience, recorded this video, or prepared this paper on a given subject.

An invitation for future experts

Software development is a team sport. Every day there are a few hundred thousand software developers starting their careers and doing their best to become better and better. But what are they able to do without access to the knowledge of those who are more experienced? Well, they will waste their time doing the same mistakes as someone in the past. They will get frustrated because of inefficient tools or guides that block them from growing. Finally, our own projects will be in trouble because there will be fewer people who could contribute to the projects and join the teams we work at. In this context, knowledge sharing — while requiring some time — works as an investment for future self. Let other people grow by sharing your own story with them.

It’s worth it

Our potential to push the industry forward is much bigger than we could think about. What really bothers me is this relatively small percentage of people who think about it in that way.

There are hundreds of super experienced people who think their knowledge is not worth talking about, and as a result, we are not able to learn from their wins and failures. We need to do our best to convince those people that we want to listen to their stories and as a result — create something better and more valuable for all of us.

Because it's worth it.