DEV Community: Lucas Wonderley

Managing cognitive load

Lucas Wonderley — Wed, 06 May 2020 04:26:46 +0000

Doing challenging technical work can starve your social and creative sides because it forces you to strive for correctness all the time. You have to take deliberate steps to maintain a sense of balance, well-being and humanity.

I find joy in the abstraction, logic and ingenuity that software development entails. But the work can take a toll.

To debug effectively, you have to think like a computer and play out how a system works in your head. Do this for many hours every day, and you may begin to feel like a computer yourself.

Our work affects us more than we realize. At times, afraid I might permanently lose touch with the other parts of myself, I've considered quitting engineering entirely.

But the underlying problem of getting sucked into technical work at the expense of other parts of one's life and personality isn't a sad reality to be accepted. The issue can be avoided. I've found that the key is managing cognitive load.

Put another way, you’ve got to avoid overworking your brain’s RAM. Never let it spin too hot for too long.

Following a few guidelines makes a huge difference. For one, you can give your intellect a rest by walking or exercising. Anything physical is going to make your mind work less.

Slightly less obvious: creative and analytical tasks use different mental muscles. Take advantage of this distinction by taking creative breaks to rest your analytical chops.

Seek out conversations about something other than that problem you’re solving. A simple chat can be a fun way of remembering that not everything needs to fit into a perfectly logical box.

I like listening to podcasts in a language I’m learning to get some extra low-effort exposure. This isn’t for everyone, but for me it's a fun way of switching things up during the day. Things like this can can keep you sane and balanced. Know what they are for you, and consider setting goals for them so the time you spend doesn’t feel wasted.

Finally, use a system of notes to record your thoughts and ideas in digital or paper form. Make lists and draw pictures, and revisit them often. By writing down what you’ve already figured out, you give your mind more space. This keeps it from getting bogged down.

It is possible to do technical work without feeling like it's turning you into a robot. Coding doesn't have to be antithetical to being social. You can embrace being a nerd, be successful in your career and still be a real human being in the rest of your life. It just requires self-awareness and being disciplined with your time.

Why you should use Unix time in your apps

Lucas Wonderley — Wed, 06 May 2020 04:20:12 +0000

Seconds since 1970, January 1st at midnight: The Unix Epoch.

This way of representing time, called Unix or epoch time, is common in software because it makes it easy to get dates and times right.

What makes it useful? I don’t know about you, but for me, a big integer isn't a great way of talking about time. For example, August 17th at 05:27:49 AM Eastern Time seems a lot more intuitive than -485188331, which is the Unix time version. But more familiar formats also have a lot of problems that Unix time avoids.

For one thing, there's no confusion over time zones! It’s based on UTC, period. This means just a bit less mental overhead for system builders. Unix timestamps unambiguously refer to the same moment in time, wherever your code happens to run.

And working with it is simple. How many seconds are between two timestamps? With Unix time, you just subtract. No separate data structure needed to represent a duration. Want to convert seconds to hours? Just multiply by the number of seconds in an hour, or 3600. Milliseconds or smaller fractional seconds are decimals.

With modulo division, you can even check the number of hours since midnight of the current day, the number of minutes since the top of the hour and so on. And the simple representation makes it easy to write tests with canned data.

Simply put, it’s easier to build and reason about systems based on Unix time than with more human-intelligible formats, which have to be converted to a data structure and are liable to misinterpretation.

But why is it based on the start of 1970? Apparently the standard was invented in the early ‘70s, and it seemed like a reasonable thing to do. Fair enough, ‘70s computer science pioneers.

In software, Unix time is ubiquitous. Most libraries have a way of converting it to a human-readable timestamp and vice versa. The characteristically descriptive Swift programming language provides a timeIntervalSince1970 API. JavaScript returns the same value in milliseconds (in other words, multiplied by 1000) when you call getTime() on Date objects.

One downside of Unix timestamps is that they are less human-readable, which you have to account for while debugging. You can work around this with utility functions for printing human-readable timestamps. You can also convert between Unix time and other formats with tools like epochconverter.com.

Of course, if the first second in 1970 has a Unix time of 0, that makes everything pre-1970 a negative number that gets more negative as you go back in time. You’ll want to take the absolute value to do modulo division. Other basic operations work fine with negatives.

Now, because nothing in internationalization is as simple as we’d like, there is a rub. Leap seconds, or extra seconds that are prescribed by scientists from time to time, are accounted for in Unix time by double-counting. Those extra leap seconds actually have the same value as the second before them. This makes Unix time not a true representation of UTC!

International atomic time (TAI) is an equivalent system which includes leap seconds as separate timestamps. This means it gradually gets out of sync with earth’s rotation by roughly a second per year. But in return, it avoids duplicating values. In my experience, ordinary Unix time is the standard, but TAI may gain popularity, especially in domains like time-critical domains finance and aerospace engineering.

Use Unix time to represent time in your apps! It’ll make your code easier to understand and less error-prone, so you can focus on other stuff.

Leadership, not talent, predicts organizational success

Lucas Wonderley — Thu, 30 Jan 2020 02:40:47 +0000

The software industry has a well-documented talent shortage. But an organization's success isn’t a function of their hiring process or how many developers they can lure in with salary and perks. In the end, it all comes down to leadership.

It’s true that there are relatively few senior developers, compared to the market demand. It's hard to find people who can pick up a complicated, multifaceted problem and understand what it takes to drive it to completion, let alone convince them to work for you.

Yet great developers don’t appear out of thin air. Every senior engineer had to start somewhere. They worked hard, of course, but many were fortunate to do so in environments conducive to growth. They probably had numerous role models, teachers, and encouraging peers.

Managers sometimes think of engineers as business resources to be deployed strategically, like time, money and office supplies. This perspective is valid and necessary for planning. But please, don't forget that developers are people.

To generalize, software developers tend to be a passionately analytical bunch, often with at least a dash of creativity. They're also sensitive and particular. If you lose sight of this and treat your team like cold, mechanical assets, you'll be forgetting that the value of these specific assets can appreciate over time. In the right environment, even a very junior developer can pick up things quickly and find inventive ways to improve the whole team's productivity.

On the other hand, an unhealthy environment will stifle this very ingenuity. If anyone perceives that they don't have the support they need to be successful, or if the culture is toxic in some way, morale will decline. As a result, the very creative and determined spark that teams need to push through challenges will be missing.

What makes for a healthy, optimistic team culture? As Ben Horowitz points out in his book You Are What You Do, there's no magic bullet to building a great culture. And for that matter, there's no objective formulation of what a great culture is.

However, it's clear that leadership is the essential lever for influencing culture. The behavior of a leader forms an implicit model for how the rest of the organization will think and behave. It's crucial to foster a growth mindset and an attitude of continuous experimentation. This will allow your team to improve, and to dynamically adapt to changing circumstances.

Even junior-level individual contributors can be leaders when they exert influence over the organization's culture through their actions. Culture is a self-reinforcing system whose inputs and outputs are everyone's behavior. But the appointed leaders tend to have more power, and therefore more responsibility, to set a positive and encouraging example.

Whatever their specific duties may be, great leaders are humble and see themselves as enablers, not bosses. They pay attention to others' talents and needs.

It's not enough to merely plan and delegate. You need to build relationships and trust so that the team can self-organize. Otherwise, no matter how talented you are, you're still a bottleneck. And even if your team has world-class technical skills, they need a healthy culture to reach their potential.

Building a website is hard: Discovering the JAMStack

Lucas Wonderley — Wed, 22 Jan 2020 05:52:32 +0000

Building a website is surprisingly hard.

As a developer, I tend to scoff at the idea of using a popular tool like Wix or Squarespace. I can build it myself, and I’ll have so much more control!

My background’s in mobile, not frontend development, so my first real foray into building a full website was only a few years ago.

I was getting married. Naturally, I took responsibility for building our wedding website.

It turned out to be a bit trickier than I expected. I’ll spare you the details, but I gained a newfound respect for how complex, powerful and occasionally bewildering CSS can be.

I’ve learned a bit more about frontend development since then. I love how React lets you combine the best parts of JavaScript and HTML and you modularize the result, and how it handles the complexity of rendering optimization. I also discovered Gatsby, which makes it easy to work with all sorts of data types and resources with a GraphQL querying layer.

A visual description of how Gatsby works.

Before Gatsby, I learned that you can create a GitHub-hosted blog using another tool called Jekyll. It’s amazing because you can customize the site’s pages and templates as needed, and simply write your blog posts in Markdown. Push a new Markdown file to the repository, and you just published a new blog post!

Gatsby elevates this story by letting you use React to build your UI. Its integration with GraphQL lets you pull in text from Markdown. And you can use the same querying interface to pull in data and resources, whether it’s from local files or remote APIs.

The set of tools for building static sites that are also interactive and dynamic has become known as the JAMStack. With JavaScript, APIs and Markdown, you can build a modern, lightning-fast site that lives entirely in the browser.

And then there’s Forestry: A UI layer for content creators that makes all this Markdown editing feel like it’s happening in a real CMS, similar to writing content in WordPress.

Yet even with all this, there’s a huge chasm between what we can hack together as developers and what you can do with Squarespace or Wix. There’s no guarantee that it’ll look good. And you can’t edit stuff in place and see what it feels like. If you’re a designer, or you’re just attempting to think like one, it’s helpful to see what content looks like in real time.

Site builders and customizable CMSs both have tradeoffs that make it hard to build a site that's both beautiful and interactive.

In a recent talk, Forestry CEO Scott Gallant used the above diagram to show how the Gatsby/Forestry solution can be frustrating for both developers and content creators. As powerful as a code-friendly CMS is for developer productivity, developers need help creating a beautiful design. And creators are likely to struggle with editing code. This makes the Gatsby/Forestry solution a bit frustrating for both developers and content creators. Gallant announced TinaCMS, a new product that attempts to deliver the best of both worlds.

For now, we’re still in this awkward position where it feels like building a website is more difficult than it should be. There are probably lot of people who aren’t professional web developers but nevertheless want to go a level deeper than what simple drag-and-drop tools allow today.

It’s encouraging, though, to see how the JAMStack is bridging the worlds of using a code-free CMS and of building a site from scratch. Over time, this will empower more people to create original, creative websites, and lead us toward a more innovative and interactive web.

Keeping your sanity in the face of tough deadlines

Lucas Wonderley — Sun, 29 Dec 2019 16:24:26 +0000

When work gets stressful due to deadlines, mistakes and difficult people, your favorite thing can become your prison.

You love to code, but suddenly a herculean slog of development and debugging stands between you and basic sanity and well-being. You feel trapped by your own passion.

It’s necessary to prioritize your well-being above everything else. If you start to feel work crossing that line, it’s time to take a timeout and a step back.

Get in the right head space. Do something else for a while. Read, play, be with the people you love.

And if you get the chance, find a way to remind yourself that you still love what you do. Work on a project on your own time that’s just fun to you and has nothing to do with your day job.

This last suggestion may be counter to most common advice about avoiding burnout. I can hear you say, “More coding? That’s the thing that I’m sick of in the first place!”

I think it’s more likely that you’re sick of dealing with unreasonable deadlines and people. You’re worn down by scheduling pressures that have built up over time. It’s the current, temporary situation that’s unpleasant and unrelenting.

All this has nothing to do with what got you into software development in the first place. You can remind yourself of this by working on your own stuff, on your own time. This will prevent you from strictly associating software development with pain. Building stuff can be fun, remember?

Maybe you even had a role in causing the situation you’re in, and your guilt around that has been fueling you to slog on. Good - you can learn from the mistakes that got you into here and avoid repeating them. That lesson is one of those hard-won rewards that comes with experience.

Of course, none of this will make the painful situation go away. When you come back to work, the problems will be there waiting. But you’ll be fresh. And your outlook will be calibrated knowing that this challenge is temporary, and in the grander scheme of things you still love what you do.

Do a little more testing!

Lucas Wonderley — Sat, 28 Dec 2019 22:39:15 +0000

Even when you’re confident in your work, add a bit of extra caution for good measure.

When you think you have a fix, don’t say so right away. Verify more than you want to.

If youre not careful, you can make mistakes and cost everyone’s time. It won’t be a huge deal, but it’ll be annoying and a little embarrassing.

You’ll want to show all your coworkers what a great engineer you are. You can see the whole thing end to end - it works, it makes sense! Isn’t that great? Ship it!

It takes some emotional maturity to resist that temptation. You have to be deliberate about pumping the breaks.

Even in the most agile and fast-moving organization, the experienced developer knows to mix the excitement with a healthy dose of caution. Move fast, but try not to break things. 😄

Do you scale?

Lucas Wonderley — Sat, 28 Dec 2019 22:36:53 +0000

As an engineer, “You don’t scale.”

A very senior manager once told me this as career advice. The point was, to advance your career, you will need to manage people and climb the corporate ladder. You can only write so much code in a day, so your impact has an upper limit. Is this true?

In software development in particular, we think a lot about scale. We like our solutions to scale. It’s one of the holy grails of a great product. So we tend to tacitly assume that our careers must scale, too. Suggesting otherwise is like telling us our code is buggy: it’s counter to our intuition, and probably our ego.

Somewhere in every dev’s consciousness is the mythology of the 10Xer: A great engineer can increase their team’s productivity by an order of magnitude or more. There’s exaggeration and truth in this.

Yes, even great developers can only do so much in a day. Whether you work for a startup or a big company, you’re just one piece of a larger machine that can have many bottlenecks. And typically devs are viewed as a part of operating costs. They’re a necessary evil as far as the balance sheet is concerned. They don’t create revenue; they’re just needed to help the business deliver on its commitments.

But bad development and management decisions can certainly cause a project to advance 10 times slower. In software, where complexities multiply at every turn, clarity is golden. And that comes from experience.

Today more than ever, it’s possible to have an outsized impact. For one thing, consider the power of online content. A great developer can evangelize and build community around a technology by giving talks, creating content and interacting on social media.

Also, in this age of digital transformation and heightened consumer expectations, technology architecture is becoming more enmeshed with business decisions. Retailers, construction companies and mom-and-pop shops alike must take their stack seriously just to provide an adequate experience for their customers, let alone get a competitive edge. If “every company is a software company,” even the suits need to be technical.

So personally, I don’t worry about not scaling. I try to have faith that if I keep learning and building stuff, good things will happen. Software (and, uh, life?) is magical like that.

Code reviews

Lucas Wonderley — Wed, 25 Dec 2019 22:42:50 +0000

It's hard to review code. You'd often much rather keep focusing on your own work. Code reviews break your focus. They also force you to interpret changes without seeing them in action, and without the assistance of an IDE. The result is a high cognitive load (it takes a lot of focus and thought) and a seemingly low payoff (it's someone else's work you're helping push forward, not your own).

I've found that with code reviews as with many things, a willfully stubborn attitude is key to doing it properly.

Next time you review someone’s code, try this. Pretend you submitted a PR yesterday and woke up today with no memory of having made that change. The code is already approved and ready to merge, but you don’t remember writing it!

So, would you merge it into production? Of course not! You'd need to be sure to understand what that code says because it’s got your name on it. You'd go through every line of that change and visualize how it works in real time. You’d think about the design implications. You might even test it out yourself.

So it is with reviewing the work of your teammates. Even if it’s not your change, you’re accountable for its quality. As a leader and a good teammate, it’s important to go further than eyeballing the change. You have to take it seriously.

It might take more of your time than you want to spend. So be it! Be stubborn in your insistence for deep understanding. The resulting software will be less buggy and easier to maintain. And your teammates will appreciate your commitment to making their work better.