leadership

I often hear in many organizations: "Don't be such a problem-oriented person!" or "We want people who are solution-driven." This is nonsense.

As a leader, my job is constantly reminding engineers that we ARE solving problems. A solution is, by definition, the next step.

It's all too easy to be tempted by a specific solution we want to implement (using new, shiny tech or writing some pattern) that we forget about what we're doing and why. 

Looking at the problem first is a prerequisite, but it's not always easy to identify the actual issue. That's why we have so many tools to help us find the 

 problem or decide which problems are worth solving (we can't fix everything). Tools like root-cause analysis help in discovering underlying issues, instead of just addressing what we see on the surface.

For developers, one of the common issues I encounter is a stack of fixes and improvements for features that nobody ever needs. This includes:

Fixing and maintaining workarounds that should never have been written

Finding complex solutions for complex problems, instead of seeking simple ones

Trying to solve everything with code, when often we don't have to

Good product engineering should always remind us: What problem are we solving right now?

Being problem-oriented doesn't mean dwelling on negativity. Instead, it means maintaining a clear focus on the challenges we're addressing. This approach ensures that our solutions are relevant, efficient, and truly valuable to our users and stakeholders.

By cultivating a problem-oriented mindset, we can avoid wasting resources on unnecessary features or overly complex solutions. It encourages us to think critically about our work and its purpose, leading to more effective and meaningful outcomes in software development and engineering as a whole.

Why engineerings should seek problems instead solutions

Be a Problem-Oriented Person

My perception of a good leader is a servant leadership model. Although I am far from being mature in this area, I always try to follow this rule: solve other people's problems first.

As an individual contributor, I had the luxury of claiming a task and focusing on delivering it. My professionalism would end with being good at the work I owned and direct communication around this unit of work. Other people's problems were not exactly my problems.

What has changed on my leadership path is the realization that we can achieve more as a team than as a group of individual contributors.

If a "misled team" works in isolation, they are not strengthening themselves; they can even be less performant than a smaller team (due to communication costs). But when the unit is led well, they establish synergy, not only multiplying their work (assume five developers = 500%), but also sharing knowledge, distributing tasks for the best knowledge fit, etc. (which adds more % to the equation).

I believe a good team will eventually learn how to work without a clear leader, but it takes time and education. From a pragmatic perspective on the market, I think the leader should be the one who builds the synergy.

One example is solving people's problems. It doesn't have to be technical support (see the next section), but rather unblocking others from whatever obstacles they face during their work, such as making a decision, looking for people who can make the decision, planning work in the most effective way, cutting scope and overengineering rabbit holes, saying "no," giving emotional support that is paid long term. On a daily basis, I take personal responsibility to ensure everyone has everything they need to do their job, and when I have time left, I work on my tasks. I often can't afford to take a bigger task because I know I can delay it.

It can be challenging - it's hard to see your performance and skills when you don't produce high value individually. But it pays off when the team delivers value.

I don't feel comfortable claiming to be "the A player," but from my experience, most leaders transition from at least "very good" specialists to leaders. I'm not sure if this is the best scenario, but I think it's quite common (good knowledge -> starts making decisions -> becomes a "leader").

Being good is a nice feeling. It's confidence in the market, and your position in the company is high, and supporting less experienced people is noble.

If you like the feeling of being "good," you will likely want to be good in the new role of a leader. It requires time and training. You cannot be the best in every area; you have to choose. If you want to be a good leader for your team and eventually evolve in this area, you must accept the cost - the better leader you become, the less time you will grow as an individual programmer. Others in your team will likely start to become better than you.

This is a normal thing, but it can be hard to accept.

Being said that the team is more efficient than the individual contributor, it also changes the priority. People deliver long-term effects, but people are much more complex than technology. They are not driven by an algorithm but mainly by emotions. Some of them can handle their feelings, and some of them not. We can't fire people because they have a bad day or underdeliver for a while. People spend 1/3 of their life at work - we can make it hell for them, but they will be far more effective if we care about them.

While technology decisions can be delegated to the teams, solving "people" problems is much more delicate and requires very difficult skills, including empathy and communication.

Highly motivated people can be outstanding at work and attract more talent. People who are sad and demotivated will rot and destroy the organization.


This one is a little connected to not being a "top" performer anymore. I like to model personal development in some kind of range, between a highly specialized model ("I am the top x% in my niche") to a very generalistic model ("I connect the dots at many diverse areas"). Personally, I believe best in the T-shape model (one specialized "leg" and some range of areas around it).

In software engineering, it's easy to be specialized. You can be not only a "great frontend developer" (which is quite a broad area anyway) but specialize much more - "top JS expert," "top React expert," "top animations expert," "top performance expert," and much more. Assuming you don't bet on something "dying," it will pay you off.

But I struggle to reflect on this specialized model of leadership. I don't believe I can learn some narrow "leadership skills" and be effective.

Leadership is a range of skills, and I believe a good leader must have "some" experience in many of them:

Good enough technical expertise (non-technical leadership is controversial)

Empathization, understanding people's problems and needs (psychology areas, emotional intelligence)

Ability to build good and sustainable processes

As a leader, I'm no longer responsible only for myself - now it's not only my job to be delivered, but my job is that others must deliver.

It's hard. Not only asking your team, "why does it take so long" but also protecting the team from other stakeholders with expectations. You can be squeezed by the team ("help me with...") but also by your manager ("make your team work faster").

This is a pressure that is energy-draining, especially if you have (you should have, I guess) the feeling that if something goes wrong, you are the first one to fix it.

You can probably imagine that you can earn more money and have more power in a leadership position. But it has costs. Some of us just don't want to have all of these responsibilities and just focus on engineering. Some of us feel badly forced to communicate at the first line with stakeholders, and some of us need better work-life balance (balanced into "life" direction).

I think we should speak in loud that leadership is not for everyone and feel free to step back if we feel bad in this role.

My mental model shifts on software development leader role

Leadership mental model shifts

programming

javascript

), for little more nested objects it gets more complicated - we need plain redux-like operations (

const newState = {...oldState, {something: ...oldSomething}})

). The deepest it gets, the worse it looks. There are libs like 

 that hides deep clone behind proxy (which is fine but it also introduces mutable-like API and also bundle size).

For cloning objects with unknown structure, you need either a 

 hack (which is slow and not recommended), a custom recursive cloning function or a common lib (which is e.g. lodash.cloneDeep)

However, recently a new built-in API arrived - a top level structuredClone function!

const newObject = structuredClone(oldObject)

Its available in Node 17 and all modern browsers now.

https://developer.mozilla.org/en-US/docs/Web/API/structuredClone

https://lodash.com/docs/4.17.15#cloneDeep

You don't need lodash. cloneDeep()

management

productivity

The idea to write this came to mind mind watching 

I don't treat these simple tests useful - IMO they are a little like horoscopes.

However, Gallup is a different leage for me. The Gallup Institute has a good brand of sociology and big data studies. Their assessment is more complex than popular MBTI, etc.

Important thing for me is to treat Strenghtsfinder as a model, knowing its limitations. Its not meant to tell anyone how to live, what to do etc. I consider it an ordered list of common behaviours, models, opinions. Of course its positive psychology attempt, so even something "bad" in my opinion is an asset in assessment.

Mapping Strengthsfinder to my own personality, I have a distance and use it for self-development. But, I find it also interesting working with people

Here are some use-cases I've been using last 5 years with my personal development, people management, relationships.

Entrance to self-awareness and self-development. I wasn't into that before assessment. I wasn't aware of my good and bad parts. After reading about my results, I realised that some of my behaviours are modelled and I share them with other people. I started to read and work to improve them. Especially useful were some of strengths that are statically not common in society (command). In gallup terms I had my top strengths in their "basement" and I needed some work to realize them and improve them.

Ability to quickly "model" personality of people I work with. It takes time to know person, especially working remotely its hard to build a good team in finite amount of time. To be effective, especially as non-that-empathetic guy, I find useful knowing people's behaviour model. For example, knowing that I work with super-analytical person, I will rely on data and facts, giving this person space to ask questions and analyze data. I can pair this person with "activator" archetype, who will push forward action. It's not *that* simple, but ofter - it works.

Understanding people - its easier for me to read about archetypes different than I am, to widen my perspective. Gallup archetypes are good for me, I can read about something very unfamiliar to me and say to myself "right, so there are people thinking this way and I must respect that"

A common language to descrbe behaviors, as a non-specialist. So, psychotherapists can describe proffessionally some models and behaviours, but normal people can't. With Gallup Strengthsfinder I can use similar language with my friends who also work with Gallup and describe our thoughts with 34-strengths abstractions divided into 4 domains

In general - I like it and if I can - I'd like to have everyone done it. For some of them, to help them, for others - to help me work with them 

My thoughts on Gallup Strengthsfinder assessment and practical use-cases

Gallup Strengthsfinder: practical use-cases

This is basically non-tech, I don't include here very tech specific stuff, but this system includes my dev work too

Todoist for tasks management, planning, reviews

 for planning complex projects (software, building a house)

I use Todoist with my wife, to handle all home/family/dog related stuff and exchange work

I use Todoist with some of my friends, which is rare, to run shared projects

Each area can, but doesn't have to have other areas. For example, Health contains Sports area, Sports contains Running area, Running contains specific goal projects (e.g. Business Run 2022). I use Todoist project nesting for this.

I name areas UPPER_CASE and project PascalCase. I use emojis

Area is project without any specific goal and it's not meant to be closed. Project is short living and meant to be executed and closed.

I plan reviewing every area every 12 weeks

I use Todoist inbox to put there almost everyting, trying to recude number of inboxes. 

. I plan my next week with Todoist nad calendar. I check free slots in calendar and put Todoist dates to fill calendar evenly. 

I use many Todoist filters to switch contexts, e.g. "next week, without job" or "important without dates".

I use many labels/tags, which I use to batch tasks, e.g. "phone call" or "grocery"

I use power emojis 🔋🔋🔋 / 🔋🔋 / 

 - to mark tasks energy / complexity. I plan maximum one complex task per day.

I use several calendars (job, few private and shared accounts). I need good app (Fantastical) that merges them and allows to me switch views. Fantastical has first class Todoist API integration, which is not a calendar subscribtion, but actual tasks integrated into calendar. I can e.g. finish a task from calendar.

Every Sunday I review my previous week nad plan next one.

For projects like building a house I need something more complex than Todoist. At the moment I use Clickup for that. I'm not a fan and I think this app is quite bad, but it has reasonable amount of features in free plan (Gantt)

I use Spark to connect my accounts. I use inbox zero. I'm not connected to Spark, they focus on team work which I don't use. One day I will look into something else, but I don't like MacOS client

I was researching a lot of tools and systems here. Notion-like apps works for me the best at the moment. However, Notion is slow and has quite poor search, it's online first.

I discovered Craft, a native, offline-first app on Apple ecosystem. They have instant search which is very important for me. I don't care about documents hierarchy, because I build content for extreme searchability. 

Personal productivity framework - mid 2022

patterns

I often use Axios in my applications - it provides a set of sane defaults compared to the native Fetch API

When I write my RESTful clients I often write some specific classes to operate on a single resource, for example implementing this interface:

At this point, I'm not interested in how it's implemented, because I design my high-level abstractions and communication between them.

Later, I want to implement it. I assume I will not change Axios in the near future so I implement this interface lightly coupled to 

So far so good but a problem appears. I want to test my class. Maybe there is not a lot to test, but a real example will be a little more complex - like data validation and error handling.

I want a unit test so I want to inject a dependency into my class, which is 

 to the constructor so I have an elegant way to control what will be returned from API. But this is not an elegant solution. I have to either suppress Typescript or do some spy/mock etc. 

In this simple example it might not sound too bad, but let's see what is the issue here. I did implement a fake get() method, so this code should be perfectly valid. The problem is, that I unwillingly expect more than I actually need.

And this is the interface segregation principle in my practical understanding:

Clients should not be forced to depend upon interfaces that they do not use.

 interface to be exactly what is needed in my class:

And that's it - one simple line of code, the client didn't change its behavior, but the code became more composable, reusable, and testable. Mock can be easily passed in test, any code substitution will be easier, code is less coupled and more elegant.

Of course, this is a simple scenario, but it's valid almost everywhere. Just remember to narrow down dependencies only to the smallest needed subset.

For example - React components should require a minimum number of props that are required to render data (e.g. 

I hope it will help you understand the practical reasoning behind ISP and let you write more flexible and testable code.

Practical example of ISP principle using frontend case and Typescript code

SOLID Interface Segregation - real life scenario in frontend and API client

typescript

antipatterns

It's tempting to use certain data types when we start coding because they seem to be simple and "good enough" at the moment.

Unfortunately, careless data modeling can be very bug-prone and hard to maintain in the future

Boolean types are super low level and they are core of computer programming. But in real-life - which we try to model in our applications - it's not common to see something 100% binary.

An example of too simple primitive usage can look like this:

It works as long as our app is a prototype. But when app grows it quickly starts to look like this:

...and it's only related to the user's auth/register status

This is not maintainable, we also can't ensure that our model is valid from a business perspective. We can assume that users can be either enabled or activated, but it's easy to make them both "true" by mistake.

 primitive which is respected by Typescript's 

In a few other languages, developers are more flexible, allowed to declare nad user integers, floats, etc.

When modeling business models, we want to make sure out "number" is the number we want it to be:

Product count in e-commerce cart - integer, 1 or more

Product price - floating, 2 digits precision, 0 or more (assuming it can be free), with currency 

All of these types can not be modeled in Typescript.

 is an immutable data wrapper without identity (so it's compared by value, not reference). It provides some functionality we should consider writing the code. In backend programming, it's a popular pattern (especially in DDD), but in frontend and/or typescript it's not that simple, also due to language limitations.

The example value object can look like that

It's a start, but far from the final goal. Typescript is a structural type language (duck typing), so there is a problem:

. This is only type-level behavior so TS doesn't check and constructor runtime checks. What it does is check field by field if the type matches the expected result. 

 is a number? It is, so TS doesn't throw. Runtime check is also omitted.

To alter this behavior, we must introduce a 

 field so the language can't compare private fields anymore:

Now we can perform logic using value objects with safety:

Most likely we can create our value objects in different ways. We can use a factory method pattern

A constructor can be made private and we expose several ways to create this class (including deserialization, cloning, etc)

In TS we can not override the behavior of 

We are creating 2 independent instances with different references, so we can't compare them yet (

To enable this, we need to write our one equality function

I can validate data and ensure its safety in the runtime

I have strong(er) typing by enforcing nominal typing

I have a clear understanding and context of each value object, knowing what is its business counterpart

I can scale and extend my data, not being limited to primitive values

Learn how to migrate limited primitive data models to type and runtime safe data abstractions

From primitive obsession to value objects in Typescript

styled-components

emotion

styling

The important thing in programming is building abstractions. Components in UI frameworks are abstraction building blocks. We encapsulate complex 

 to hide details we don't want to know or see in 

 and only care about its data when embedding on some 

This syntax is very clear for me. When I use 

 I know I hide some component beneath. But when I have 

 I know it's a primitive node that I use for layout purposes.

I have literally no idea how this component builds on abstractions because we use 

Another problem is common practice to move the styled part to a separate file, ending with 

Now, my IDE experience sucks. I want to import 

The global scope gets polluted and we don't use any namespaces to give them a context.

To sum up, I hate codebase with this type of architecture. Developer Experience sucks, its easy to make a mistake, hard to refactor (duplicated names) and unreadable.

 we can actually use custom components without being forced to use PascalCase!

With this knowledge, we can solve 2 problems at the same time - global exports and naming problems by a simple convention

The first problem solved - I will no more import some orphan Wrapper now because I need to explicitly import 

Later, just use it as a namespace! No more confusion, clear separation of styled elements and native HTML nodes.

Of course, you can prefix it however you like or maybe just stick to the full name. 

Learn how to make your React components more readable with Emotion or styled-components 

Improved naming convention for styled components or Emotion

recruiting

employer branding

For about 18 months now, I have been running dozens of recruitments processes in my current company. As an engineer, my job was not only to run technical interviews but also to 

Recruitment isn't that easy - you need to know who you want to recruit first and what skillset you need. Do you need a senior engineer? If yes - why? What are the senior 

For some companies, the senior engineer will be extremely good at software performance, for others - good social skills and the ability to understand business.

In your company, the recruitment process can be treated as an ongoing "project" itself. There are several people involved. There are HR managers, team leaders, technical interviewers, etc, who need to 

 on daily basis and share knowledge about processes and candidates. That part also isn't easy, and if you don't make it right, it will be noticeable for candidates - 

Nowadays, recruitment can be a crucial part of the company's growth. Everyone needs programmers, almost everyone struggles to hire them. And not everyone is among 

 which for some reason are considered El Dorado for some people.

Recruitment is tightly coupled with employer branding.

✅ A good process can start with slight attention, but end with a strong will to work with you - candidates might be intimidated by your professionalism, atmosphere, technical skills of people working at your company. It's a moment, where you can advertise your company among them.

❌ The bad process will tell them, that you are desperate, your projects suck, your developers are poorly skilled and you waste their time.

Remember - as long as companies need programmers more than programmers need companies - the effort to make it right is on companies.

How about junior developers? In Poland, where I live, salaries and offers for senior engineers grow fast as hell. But for entry-level engineers - they don't. We receive a lot of resumes of people we can't and don't want to hire. Is it still an employee market here? In my opinion not - while we still need to be professional, there will be differences. Most of the effort in recruiting junior developers should be on a candidate - because we as a company have dozens (PHP) or hundreds (frontend) of resumes for each role.

I will not write step by step what I do - it's just too much for a single article. But let me give you some advice on what I consider good and bad practices - which works for me and my company.

Consider, that I am based in Poland, where the majority of IT companies are software houses/digital agencies. Recruitment for the big American tech giants is different and they have their reasons why they do what they do (aka whiteboard programming and showing off)

Take-home tasks are one of the most popular and one of the worst things companies ask to do. The more senior developer you are, the most likely you will 

It's quite simple - they try to give you a task, which requires you to spend from 

 doing some imaginary task which doesn't make sense. Why not? Because you can't write a working application in that amount of time! Of course, you can do a hackathon-like app which is a quick'n'dirty solution, but come on - you are recruiting yourself somewhere you want to work at, right?. So you want everything to be truly good. 

You want TDD, clear commits, elegant code, elegant abstractions...

"Write app fetching beers from nearby stores and display them on the frontend, using pagination and filtering. Use React and Redux."

. Why do I fetch these beers? Who is my client? How long app will be used? And why the hell do I need redux for that?!

There are hundreds of questions you should ask before you write a single line of code. If you are an experienced developer, you realize that coding is the last and possibly quickest thing you do. You need to analyze the domain, the business context, choose a stack, and do many, many things. And they ask you, to ignore all professional steps you will normally perform because you need to fit into several hours. Ridiculous!

Ask yourself do you need to check someone's skill by asking them to write code? Coding is based on thinking, so maybe you can just make people think?

Ask candidates if they have any code they can share with you. Most likely it will be fine for you. My strategy as a candidate was to write some "classic coding task" for myself in my free time, later was sending it to several companies and no one rejected it. If they miss something, they can ask you during the interview how would you write it.

I like this one. Technically in a small amount of time you can write maybe some Katas - can be good for junior to check if they know the language itself. But complex solution (which company should be most interested in) can't be written - but maybe it 

Depending on what you want to check, you can ask several different topics, for example:

. Consider communication between backend and frontend, deployment based on workspace creation, performance reading messages history

for the UI design system. Consider maintainability for few years, focus on API-first approach and interoperability with different styling solutions.

app with entities dynamically built by the user. Focus on storing data/designing database.

The output of such a task can be a document with some nice flowcharts, some abstract models, events flow, etc. Then you do follow-up and discuss it with the recruitment team and candidate, trying to validate this solution.

I like this solution, it can show real experience and reveals how candidates think, which is far more important than writing the code itself. The downside of this solution is that it fits senior+ engineers.

Coding takes time. And it's stressful. Live coding also sucks. But what about the old truth - that 

most of the programmer's time is not writing code, but reading it

Blog

Be a Problem-Oriented Personleadership

Leadership mental model shiftsleadership

You don't need lodash. cloneDeep()programming, javascript

Gallup Strengthsfinder: practical use-casesmanagement, productivity

Personal productivity framework - mid 2022productivity

SOLID Interface Segregation - real life scenario in frontend and API clientpatterns, programming

From primitive obsession to value objects in Typescripttypescript, ddd, patterns, antipatterns

Improved naming convention for styled components or Emotionstyled-components, emotion, css, styling, programming, patterns

The good recruitment experiencerecruiting, employer branding

Handling promises in Sagasjavascript, redux-saga, redux, react

Frontend Pattern: Route Objectpatterns, react, routing

Frontend skills for the Web Designerfrontend, design, webdesign

Frontend learning pathcareer, frontend

Are you too old to start programming

Use tabs, not spaces!programming

Refactoring Overgrown React Componentsjavascript, redux, refactoring, patterns

Book Review: Factfulnesshobby, book, review

Yes, it's a good time to add TypeScript to your projecttypescript, refactoring

Code Review – Best Practices, Guidelines & Process Insightscode review, process, management, productivity

Why I read on the iPadtools

Why I dont use React Router Link componentreact, react-router, routing, frontend

Software & Hardware I usetools, software, productivity

Why public money software is not open source?programming

How learning Angular made me better React developerangular, react, programming

My 12 tips how to increase your frontend coding productivityfrontend, productivity, programming