As computer programmers, it’s easy to get carried away into the vast and interesting world of software engineering. However, we must remember that people use computers as a means to an end, they need to get their jobs done. Despite having endless possibilities of all the features we can build, it’s important to stay focused and true to the needs of our users. This is where the Jobs to be Done (JTBD) framework comes in....
Onboarding new team members can be a time-consuming and complicated process, especially when it comes to ensuring they have the right software and tools to do their jobs. Traditional onboarding documentation can be unreliable and quickly outdated. In addition, IT professionals need to keep the device fleet up to date and free of vulnerabilities. Relying on others to maintain the documentation is often unsuccessful, as people tend to disregard updating documentation as a non-essential task....
Lately, I wondered if there is a difference between a software engineer and a software developer. I tried to draw some similarities between the software and construction industries. Both have architects, developers and engineers. So, how come, a software developer can become a software architect, while it is pretty hard to imagine a construction worker becoming an architect just by accruing experience and attending a few online courses? This situation bothered me, especially after observing several software projects that had become hard to maintain and develop due to poor engineering or architectural decisions....
Designing applications can be a challenging task. Over the course of my career, I have developed a few guiding principles that I would like to share with you. These are more food for thought, rather than hard rules to follow. Throughout this article, I use adjectives like “good” and “bad” - purely subjectively. Why do we need interfaces? Public interfaces provide an overview of the capabilities of the module. If an interface and its methods have descriptive names (defined later), that interface can be a valuable addition to the documentation....
As modern front-end applications become increasingly complex, it is becoming more and more important to maintain the separation of concerns between the view layer and the business logic. New toys, old problems Having seen several modern codebases, I can say that history is repeating itself. Back in the day, when PHP was growing in popularity, but the ecosystem was not mature enough, the separation of concerns was a hot topic. For example, rushing to deliver the working code on time, people would query or write to a database directly from the views....
A colleague of mine asked a good question: does TypeScript make JavaScript a better OOP language? To answer this question, I decided to compare OOP JavaScript to its opposite, Functional JavaScript. TypeScript has become crazy popular. Many people bet on it as a magical language that will solve their JavaScript problems. Well, it won’t. As Kyle Simpson described in his upcoming book, the quirks of JavaScript don’t disappear. In my opinion, we should not attribute any superpowers to TS apart from just helping developers to feel more confident in the larger codebase....
Tailwind provides a solid base level, sort of a starting point for your application. The library is a set of utility CSS classes that use Custom CSS properties (a.k.a CSS variables). Some of these variables abstract away a default set of design tokens. As such, it is easy to create a dark theme (should a user prefer dark mode) or take some accessibility aspect into account (like reduced animations). I only described the tip of the iceberg....
How do we structure a Design System? How do we make sure the architecture allows more people to contribute to it? What if there’s already a Design System in place, but it doesn’t work? During my time at Personio, I participated in the process of re-thinking the existing Design System. I noticed that dissecting the system into layers helped us answer some tricky questions. So, bear with me. How it all starts In my experience, design systems always come after the main Product....
As we progressed with our mono-repository endeavour, we noticed some weird behaviour. It worked like charm in the apps. But not in our Storybook. Besides, sometimes tests would fail for no obvious reason. Storybook is a de-facto standard tool for developing and demonstrating your components in action in the real environment. We also used Jest for testing. So, naturally, we didn’t want to give them up. Seems like our setup is not finished yet....
Let’s talk about CSS files and modules. Unfortunately, they are often treated as if they were a second class entities. We need to fix this situation. Treating CSS dependencies the way we treat other dependencies Let’s talk about the dependencies between UI components. In JS files, we mark dependencies by import-ing or require-ing them. Packages clearly define dependencies in the package.json file. But a package is not only JS files, but also CSS files....