Forem: Favour Felix

The 10x Engineer: A Guide to Building Efficient Software and Achieving Career Success

Favour Felix — Wed, 16 Aug 2023 22:33:55 +0000

I concluded reading a book titled Software Engineering: The Soft Parts about a month ago. Addy Osmani wrote the book — Think of a resource that empowers you to become a great employee, an efficient leader and a high-performing engineer—that is precisely what the book seeks to achieve.

While I read, I wrote. I also pondered some of my past experiences; some of the information here was my reality, and others still needed to be. Sharing this might be helpful to a ton of people. Hence, here are some learnings I gathered from my most recent reading:

1. Set Career Goals

As much as you can, write down goals for your career and ensure that the code you write daily helps you steadily hit that goal.

2. Invest in Critical Thinking

Try to make your thoughts clear before you start writing code; use pen and paper to visualise if necessary.

3. Divide And Conquer

Learn to Divide and Conquer: always break seemingly large problems into lower bits.

4. Understand The Fundamentals

In software engineering, the fundamentals can be classified into macro and micro levels. The macro level entails programming concepts like data structures, algorithms, architecture and performance optimisations. The micro level involves the language, frameworks or tech stack. The macro level should be of utmost concern as they are inherited essentials of the micro level.

6. User Always Comes First, Then Technology Follows

Examine what the user needs, and work backwards by trying to use the technology that bests suits the user’s requirements and needs. Sometimes, there are personnel, hiring or speed constraints. Regardless choose the best option between these constraints.

7. Learn Everyday

Learn something new every day.

8. Read Other People’s Code

Read the source code of the new and bubbly frameworks you admire—“The main value in software is not the code produced but the knowledge accumulated by the people who produced it.”

9. Leaders Also Make Mistakes

It’s powerful for leaders to admit when they don’t know something; good leaders also recognise when they make mistakes.

10. Be a T-Shaped Engineer

Aim to be a master of a skill and to have basic knowledge of other skills to get by on a project—a T-shaped engineer. Sometimes we love to satisfy our curiosity and explore new technologies, but building capacity in a particular tech stack would make you a force to reckon with.

11. Less (Code) is More

Less code is always better code; adding redundant functionality increases the complexity of your code.

12. Technical Debt Isn’t Always Bad

Always prioritise speed, progress and simplicity; sometimes, this might result in technical debt. A technical debt is okay if the cost of the debt has been counted, and plans to pay the debt as soon as possible are implemented.

13. Abstract Complex Code

When complex solutions require complex code, a good practice is to abstract complex code. For example, complex functions, interfaces, or classes can be abstracted in a separate file, package or module.

14. Not All Old (Code) is Gold

While there might be good reasons for some specific code to exist in production, when working with legacy code, we should still question whether every line is needed or could be done better.

15. Define Project Requirements and Completion Criteria

Defining the criteria for a project’s completion helps save time and unnecessary revisions. We must also remember that we are never satisfied with every feature we have built.

16. Make Deployments in Digestable Sizes

Releasing updates in smaller chunks to users help to manage risks better. Large changes could have more significant impacts on users.

17. Read Error Messages and Stack Traces

Always read error messages and stack traces before looking for solutions elsewhere.

18. Document Systems and Processes

Creating documentation for your internal design system is super important, and it helps all stakeholders on the project in the long run (new and old)

19. Communication is The Most Crucial Part of Your Job

Admittedly, Communication can be challenging for engineers, but it is extremely important — possibly the most crucial part of our job.

20. More Growth Equals More Communication

As we grow in our roles and climb the corporate ladder, we must understand that this equates to more communication. Promotions almost always require us to have better communication skills.

21. Know When to Speak in Technical Terms

Avoid using OVERLY technical jargon when talking to a business-focused stakeholder. However, a business person needs to be aware of technology decisions from a low level.

22. Simplify Product Decisions and Outline Possible Implications

When talking to decision-makers like Product Managers, it is best to describe available options and the implications of all of these options.

23. Progress Updates Are Only Concerned With Hitting Project Goals

When giving status/standup updates, we should always provide an update that is particularly relevant to the project’s goals.

After discovering these crucial lessons, I have since tried to be conscious of them and act accordingly. There are still many more lessons from the same book, and I will share those in another article.

I hope you found this article helpful. If you did, feel free to connect with me via favourfelix.com to see what else I'm writing and up to.

CSS and Motion — You Too Can Build Animations on The Web

Favour Felix — Mon, 26 Sep 2022 22:15:08 +0000

Who doesn't love animations? More than anything, they make your webpage feel alive. I could take you down memory lane on how the concept of motion captured my heart, but let's talk about you. You build stunning user interfaces, and you know that adding motion to your projects would give them some sort of elegance. Hence, that missing piece has to be filled — CSS and Motion is a short and effective guide sharing just enough fundamentals to help you start developing those buttery smooth animations on your web pages.

The Principles of Motion

Understanding the Principles of Motion is essential for any motion designer or developer; animations and transitions could be used carelessly on web pages, distracting the user rather than exciting them. As a rule of thumb, ensure your animation passes some information to the user before animating any element. Also, ensure that your animation keeps your user focused on what is necessary. A good instance to use animations is at the end of a user journey, i.e. completing a milestone — this makes your animation expressive.

For some depth on motion design, see Understanding Motion.

Now that we know when motion should be used, we need to understand the two ways to apply motion in CSS — Transitions and Animations.

What are Transitions and Animations in CSS? When do I need to use one over the other?

Transitions

Transition is a motion between two keyframes; think of keyframes as a group of CSS styles, e.g. color: red, padding: 20px etc. The two keyframes of a transition would be individual styles for an element with similar CSS properties and different values — I know, that’s a lot to take in, but the diagram above helps to simplify.

Please note that the transition property in the codepen is a shorthand property, containing the transition-delay and transition-timing-function.

The code snippet above shows a simple CSS transition that steadily modifies the CSS color and padding properties from their initial state to the :hover state in one second (1s) — The CSS Transition is triggered by a hover action.

Transitions are triggered by pseudo-classes like :hover, :active, :focus but not limited to pseudo-classes. They can be added as bare styles while manipulating the DOM to activate the transition motion. A perfect example for this is exit and enter transitions.

/* NOTE: This code snippet inherits code from the codepen above */

.transition-box.enter {
  color: red;
  padding: 20px;
}

In the above code snippet, the transition is triggered when the enter class is added to the transition-box div element.

Animations

Transitions are perfect for demonstrating motion between two keyframes, but what happens when you work with more than two keyframes and need more flexibility in changing CSS properties? This is where animations build up on the shortcomings of CSS Transitions. CSS allows you to set animations with numerous keyframes in terms of percentages.

Recall that a keyframe is a group of CSS styles.

The code snippet above results to a slightly-complex CSS animation with four keyframes; 0%, 33%, 66% and 100%. Each of these keyframes have similar CSS properties and some of these properties have different values; The keyframes use percentages to represent the state of an element at a fraction of the given time, which is three seconds in this case

/* NOTE: This code snippet inherits code from the codepen above */
animation: cssnmotion 3s ease-in-out infinite;

With an understanding of what animations and transitions are, you would realise that most complex animations you have encountered in the past are just simple transitions — the developer has set up a construct that changes the value of CSS properties at a given interval.

I always recommend that animations are reserved for more complex motion designs and are seen as a last resort, as increased complexity can result in decreased performance of your webpage.

I hope you learnt a lot to kickstart your journey into CSS and Motion. Thank you for reading!

Your Guide to Hacking CSS Units and Dimensions — One Size Could Fit All

Favour Felix — Mon, 12 Sep 2022 09:09:37 +0000

Amidst the px, em, percent, and so much more units made available with CSS, confusions on the perfect units for dimensioning your HTML elements could arise. Using a unit that seems to work at first glance might trick you into believing that all is well. Sometimes, our choice of units when styling could backfire when our webpage is viewed on another screen. Situations like this make us fall back to media queries to save the day, because why not? How would I expect one CSS dimension to fit several viewports? With a better understanding of CSS Units, one size could fit all viewports.

Having worked with CSS for a really long time, I have formed various rules of thumb while working with CSS units and recycled them along the way to streamline my styling process. I believe some of these rules could help you very much as they did me.

Rule 1: Use relative units instead of absolute units as much as possible

CSS length dimensions can be represented in two units; the relative and absolute units. The major difference between them is that the absolute unit remains the same size on different screen types and viewports. The relative unit, on the other hand, has a size relative to some set constraints — these constraints could be the parent element font size or the current viewport size.

Relative units are preferable as they could help to properly size elements and fonts relative to your screen’s viewport and your HTML root element. If implemented carefully, it could drastically reduce time spent styling the same elements using media queries. A good place to start is replacing px for rem on your element’s widths, heights, font sizes and more.

Some examples of absolute units are cm, mm, px, pt, and a few examples of relative units are em, rem, vw, vh and so on.

Rule 2: Do not neglect the “max-” and “min-” properties.

As often as you use the width and height CSS properties, try to visualise edge cases where the viewport is larger or smaller than it actually is — this would help you to determine whether a min-width, max-width, min-height or max-height property would be useful in such scenario.

The “max-” and “min-” properties could be a total lifesaver in the weirdest screen dimensions.

Rule 3: Margin is not Padding, and Padding is not Margin.

In my early days as a Software Engineer, it took me a while to see the difference between padding and margin — for me, all that mattered was that they both created spacing for my HTML element. After using them repeatedly, I noticed that even though they both created spacing, they were not similar.

Padding is simply the inner spacing in the element, and a margin is the outer spacing. Knowing when and when not to use both CSS properties would help you build better and avoid dimension problems on other viewports.

Rule 4: There is always a root cause; adding and subtracting dimensions is never a long-lasting solution.

If you have ever tried to center a div manually by adding and subtracting margin and padding dimensions, this is especially for you. Oftentimes, when we try to fix code to meet a design requirement or guideline, we tend to modify the dimensions hoping it just matches what we have visualized; we could try to add a negative margin or reduce the element’s padding just to achieve that mental picture. But the truth is, taking this approach works sometimes, but other times, it could be chaotic — so why not take the safer approach?

The safer approach is the one that feels less manual and more automatic; you could explore using an auto margin; if that doesn’t suit your needs, use the flexbox; if CSS’s flex doesn’t quite cut it, CSS grids might just save the day — either way, make sure your solution does not require a lot of manual effort when it is displayed on varying viewports.

If you read this far, thank you! Feel free to drop comments and questions if you have any — criticisms are greatly appreciated too, as I have only just begun my journey in Technical Writing.