Practices Icon

Practices

Development and business practices, methodologies, workflows, etc.
365 Stories
All Topics

A List Apart Icon A List Apart

The future of web software is HTML-over-WebSockets

Matt E. Patterson writing for A List Apart:

The dual approach of marrying a Single Page App with an API service has left many dev teams mired in endless JSON wrangling and state discrepancy bugs across two layers. This costs dev time, slows release cycles, and saps the bandwidth for innovation.

What’s old is new again (with a twist):

a new WebSockets-driven approach is catching web developers’ attention. One that reaffirms the promises of classic server-rendered frameworks: fast prototyping, server-side state management, solid rendering performance, rapid feature development, and straightforward SEO. One that enables multi-user collaboration and reactive, responsive designs without building two separate apps. The end result is a single-repo application that feels to users just as responsive as a client-side all-JavaScript affair, but with straightforward templating and far fewer loading spinners, and no state misalignments, since state only lives in one place.

I won’t spoil the ending where Matt places his bet on the best toolkit to accomplish this, but let’s just say you’ve probably heard of it. Whoops!

Practices bdickason.com

Speed is the killer feature

Brad Dickason:

… teams consistently overlook speed. Instead, they add more features (which ironically make things slower). Products bloat over time and performance goes downhill.

New features might help your users accomplish something extra in your product. Latency stops your users from doing the job they already hire your product for.

Slow ui acts like tiny papercuts. Every time we have to wait, we get impatient, frustrated, and lose our flow.

Michael Irigoyen irigoyen.dev

Stop using icon fonts

Michael Irogoyen:

Continued use of icon fonts is a detriment to your visitors and a time-sink for you. By replacing your existing icon font implementation with SVG icons, you’re helping people utilizing assistive technologies, improving the quality, clarity, and reliability of your icons, and reducing your time to maintain legacy assets.

He makes a compelling case.

Miroslav Nikolov webup.org

The Emerging Ship

Miroslav Nikolov:

I want to tell you the real story behind an ambitious two-month project my team completed, with a huge impact on our organization. A very stressful, challenging, and full of surprises journey, marked by developers being the leaders. I intend to reveal why things went bad and how with a proper smart set of decisions the front-end team managed to navigate its boat.

Stick around to the end for his best practices summary.

Documentation matklad.github.io

Why you should have an ARCHITECTURE.md

If you maintain an open-source project in the range of 10k-200k lines of code, I strongly encourage you to add an ARCHITECTURE document next to README and CONTRIBUTING. Before going into the details of why and how, I want to emphasize that this is not another “docs are good, write more docs” advice. I am pretty sloppy about documentation, and, eg, I often use just “simplify” as a commit message. Nonetheless, I feel strongly about the issue, even to the point of pestering you:-)

The author points to rust-analyzer as a good example.

Google web.eecs.utk.edu

Can you make a basic web app without googling? I can't

Austin Henley:

I wanted to test my mastery of Node.js and my reliance on Google and Stack Overflow, so I set out on an adventure to make a todo list web app without touching any external resource for help. I just couldn’t do it

But this got me thinking. How many people out there, especially professional web developers, can do this?

I used to google for things all the time while programming, but not anymore. 😉

Martin Heinz martinheinz.dev

Building docker images the proper way

At this point probably everybody has heard about Docker and most developers are familiar with it, use it, and therefore know the basics such as how to build a Docker image. It is as easy as running docker built -t name:tag ., yet there is much more to it, especially when it comes to optimizing both the build process and the final image that is created.

The article goes on to cover caching, slimming, and securing your images so they’ll run faster and be less prone to abuse.

Samuel Taylor samueltaylor.org

New codebase, who dis?

Samuel Taylor (yes, that Samuel Taylor) shared a few things that works for him when joining a team and learning the codebase.

I have switched teams more often than I have had to implement an AVL tree, and you can guess which one of those two was taught in school. I wish someone had taught me how to join a new team! While learning a new codebase can be daunting, I’ve found a few things that work for me. You should do at least three things when joining a new team. The order of these three can be whatever you like, but all three should be done as soon as reasonably possible.

Tudor Girba blog.feenk.com

Developers spend most of their time figuring the system out

Tudor Girba unpacks the statement “developers spend most of their time figuring the system out.”

…reading is just the means through which information is gathered from data. It also happens to be the most manual possible way to do that, so this lends itself to an important opportunity for optimization.

Before you can do something significant about anything, you have to name it. Otherwise it’s like with Voldemort. Many winters ago, I called the effort of “figuring the system out to know what to do next” assessment. And I claimed we should optimize development around it. For a whole decade my colleagues and I explored this idea. And it led us to what we now call moldable development.

Jonas Lundberg iamjonas.me

We need to talk about your commit messges

Jonas Lundberg:

We all do it. Up to many times a day and yet it’s rare that I meet someone that has given it a second thought. No, it’s not secretly snacking chocolate from your top office drawer.

It’s how you write and structure your commits. Possibly while snacking chocolate.

What follows is a piece marrying atomic commits (as in small commits with one focus) with Donald Knuth’s literate programming. It ends with some research on whether or not this practice commonplace on the 100 most popular GitHub repos.

Practices bti360.com

What I've learned in 45 years in the software industry

Joel Goldberg recently retired after working in the software industry for over four decades. When he left he shared with our team some of the lessons he learned over his career. With his permission, we reshare his wisdom here.

  1. Beware of the Curse of Knowledge
  2. Focus on the Fundamentals
  3. Simplicity
  4. Seek First to Understand
  5. Beware of Lock-In
  6. Be Honest and Acknowledge When You Don’t Fit the Role

45 years of experience boiled down to just a half dozen insights. Staggering and insightful at the same time.

Jeff Lindsay linkedin.com

Lost potential of personal computing

I really appreciate the perspective Jeff shares in this post on what we know of as personal computing and making tools that improve our lives.

Do you remember when computers were fun to explore? Perhaps you’ve always thought computers were fun to explore, but there was a time before the Internet at the dawn of personal computing when people were excited at the potential of computers. Surely, they’ve probably exceeded most of our expectations today, but at the same time … it’s different. Did we get what we hoped for? Do we still get hope from computers now?

Brandon Smith brandonsmith.ninja

Write code. Not too much. Mostly functions

Brandon Smith has hit on a nice credo for code authoring, which he’s “stolen” from Michael Pollan’s advice on food: “Eat food. Not too much. Mostly plants.”

Code, like food, has value. I think those of us who write it can (hopefully) agree on that. Some, though, are so afraid of writing/eating too much that they avoid writing/eating what they should.

In the context of programming, I think this translates to an unhealthy fear (again, for some) of duplication. A little bit of duplication - writing something in a way that doesn’t completely maximize conciseness - isn’t the end of the world. Sometimes it’s the best path forward. Sometimes it’s okay to copy-and-modify here and there, especially when you’re still figuring out what your application will end up being.

Mikel Evins mikelevins.github.io

On REPL-driven programming

Mikel Evins on REPL-driven programming:

Interactive development with a proper repl-driven environment is the exception. Most programming is done in other ways.

As a consequence, there are a lot of programmers out there who’ve never even heard of it, who have no idea that it exists. My intuition is that some fraction of those programmers would prefer well-supported interactive programming, and would benefit from it, if they just knew what it was.

Maybe if enough programmers are exposed to that style of programming then we’ll begin to see new tools that embrace it.

Ben Kuhn benkuhn.net

In defense of blub studies

Ben Kuhn:

Over time, by consistently exploring the guts of anything I’m working with that seems magical, I’ve built up a broad base of knowledge about how various technical systems work. This helps me in tons of different ways. It makes it easier to track down tricky bugs across many layers of the stack. I can learn new languages and libraries quickly by pattern-matching them to what I already know. It gives me better ideas for software designs, by imitating other systems I’ve seen, or by reusing ideas or tools I’ve heard of in a different context. Maybe most importantly, it gives me the confidence that, if I run into a tricky problem, I can learn enough to solve it, instead of feeling like I’m at the mercy of a system too complex to hope to understand.

This is an excellent piece arguing why you should invest in deeply learning things you already know instead of something new and/or shiny.

It’s not shiny or esoteric, but for me, building a detailed mental model of those (and how they compare to alternatives) might be the learning that’s contributed most to my effectiveness as an engineer.

These mundane, highly-specific things are termed “blubs” for reasons you’ll find out in the piece.

Practices github.com

Linked lists, pointer tricks, and good taste

A conceptual explanation of two ways to implement a linked list and why Linus Torvalds believes one implementation has good taste:

[…] I don’t want you to understand why it doesn’t have the if statement. But I want you to understand that sometimes you can see a problem in a different way and rewrite it so that a special case goes away and becomes the normal case, and that’s good code

I haven’t considered linked list particulars for a long time (no job interviews lately, I guess 😜), but I found this explanation clear and illuminating. Maybe you will too.

Jacob Zelko jacobzelko.com

A terminal-based workflow for research, writing, and programming

As both a researcher and a programmer, switching between word processors, programming environments and file explorers was a pain. In this blog post, I show how I streamlined this process to where I never have to leave my terminal to write papers in LaTeX and Markdown, run code snippets directly from my scripts to a REPL, and save sessions and layouts so in just a few clicks.

A terminal-based workflow for research, writing, and programming

Devon C. Estes devonestes.com

Three classes of problems found by mutation testing

Devon C. Estes:

It’s fairly common for folks who haven’t used mutation testing before to not immediately see the value in the practice. Mutation testing is, after all, still a fairly niche and under-used tool in the average software development team’s toolbox. So today I’m going to show a few specific types of very common problems that mutation testing is great at finding for us, and that are hard or impossible to find with other methods

He goes on to detail the “multiple execution paths on a single line” problem, the “untested side effect” problem, and the “missing pin” problem.

0:00 / 0:00