Workers: DO NOT OVERWORK YOURSELF to avoid getting laid off.

- You’re damaging your life and health.
- Your employer doesn’t actually notice (no, really, they don’t.)
- Your behavior enables future mismanagement of resources.
- When layoffs come, you’re gonna get laid off anyway.

Remember that a company’s job is to extract maximum work from you for minimum pay, so your job is to extract maximum pay for minimum work. Somewhere in the middle, both parties find an equilibrium that they agree on. Do not voluntarily modify your side of the bargain to your detriment.

#FridayDevAdvice

I find that a small amount of willful belief in magic goes a long way when learning something new.

As an experienced coder, I fall into the trap of prematurely analyzing how something works and constantly peeking under the hood while learning a new library, language, or abstraction. While the desire to disassemble toys to find out how they work is great, it often gets in the way of education.

I often have to force myself to accept magical behavior in order to keep progressing in my studies. Don’t look behind the curtain. Don’t worry too much about how that animation works, or how that sound is generated, or how that data got communicated. That level curiosity is for *later*. For now, just accept things at face value—as simply magical—and continue your learning journey.

Remember that your goal is to be a *knowledgeable novice* at the end of the learning process. Don’t try to be an expert right away.

Don’t let experience get in the way of wonder.

#FridayDevAdvice #BeginnersMind

If you’re a library or service developer, be keenly aware of Hyrum’s Law, which states:

“With a sufficient number of users of an API,
it does not matter what you promise in the contract:
all observable behaviors of your system
will be depended on by somebody.”

Your primary job is to deliver a service, not an API. The API is merely a way to deliver that service. Breaking your service breaks your product, even when the change strictly adheres to the API.

Consider every change to the API (except maybe addition) a potentially service-breaking change. Have a communication channel to tell (known) clients about your upcoming change. Invite clients to test your change with you. If deploying to a service, watch your deployment, and revert it at the first sign of trouble.

With a popular enough API, there will be clients you haven’t heard of that depend on your implementation. Give yourself *way* more time than you think to roll out your changes.

https://www.hyrumslaw.com

#FridayDevAdvice

#FridayDevAdvice When creating a whole new functionality in your app (or a whole new app), prioritize validating your stack of abstractions over making each layer feature-complete.

Think of the simplest use case that crosses all the abstraction layers (connecting a view to a model and syncing state to a server, for example) and implement it. Have it do one simple thing (refresh its content on demand, say), and ensure you can test it. Then, add functionality incrementally.

Yes, that means you may need to carry a personal phone in addition to a work phone, or buy a laptop for personal use rather than browsing on the “free” one from work. But employment is temporary and will eventually come to an end, and possibly not in an orderly or amicable manner. Protect yourself.

#FridayDevAdvice

Remember that your employer has essentially unlimited freedom to retain a copy of all data on their devices. And in some cases, like litigation, they are *obligated* to retain data for legal discovery. Are you comfortable having your personal chats and browsing history reviewed by lawyers involved in a lawsuit? If not, keep that data off your work device.

#FridayDevAdvice

Time for #FridayDevAdvice!

Maintain strict hardware separation between work and personal data.

While many corporations are diligent about keeping work data out of your personal devices for security reasons, the reverse is often entirely your responsibility.

When things go wrong, or your company gets into legal trouble, you want to be sure you’re not exposed to liability or exploitation. One way to help you get there is to make sure your personal data never gets onto work hardware.

#FridayDevAdvice Schedule a good chunk of time to learn each day. Set aside one or two hours to purposefully learn something new. Read something; watch a lecture; and practice something you just learned.

You know it takes a *lot* of time to get good at something—often hundreds or thousands of hours of practice. It follows, then, that you must set aside significant time regularly to get good, or you never will.

Don’t let the busyness of your daily life rob you of your future skills.

#FridayDevAdvice During project discussions, always start with what you think would be an ideal position, and *defend it*. Don’t be tempted to undercut your ideals to please the group. Make others in the room work to *prove to you* that their position is better. Make adjustments to your position to incorporate better ideas as they come, but always stand for the ideal over the expedient.

I’m gonna tag this #FridayDevAdvice on a Wednesday, because it feels like a Friday. Gobble gobble!