Practices Icon

Practices

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

Rich Archbold Medium

My engineering standards

In this post, Rich Archbold touches on something we discussed on a recent episode of The Changelog. Specifically, in the episode, we talked about contentment being the enemy of progress and how that might effect our industry psychologically — at-large. But when is what we’re working on ever good enough? Rich has this to say… Software can never be perfect, it can only ever be “good enough”…beyond a certain size and rate of change — it’s always going to contain bugs and experience outages. So how do you know if your software is good enough? … My opinion and approach is to codify your beliefs around what constitutes software that is “good enough” into a small set of engineering principles and build a culture, organization, and set of processes that reinforce them.

read more

Victor Zhou victorzhou.com

How I fell into the trap of premature optimization

Donald Knuth famously said: The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming. You’ve either a) learned this lesson the hard way, b) learned it the easy way (by listening to others’ tales of woe), or you c) should learn it now alongside Victor Zhou as he recounts how he ignored Knuth and wasted a lot of time because of it.

read more

The Changelog The Changelog #361

Generative engineering cultures

Dave Kaplan (Head of Software Engineering at Policygenius) joined the show to talk about Generative Engineering Cultures and how they have become the goal of industry-aware tech teams. We talk through the topology of organizational cultures ranging from pathological, to bureaucratic, to generative, the importance of management buy-in (from the top down) on leading a generative culture, the ability to contribute original value which is deeply rooted in the concept of aligned autonomy. We also covered the 6 core skills required for us to be empowered in our teams.

read more

Databases abe-winter.github.io

ORMs are backwards

I think all ORM users have a journey from ‘there should be a way to’ to ‘this is saving me so much work’ to ‘I have to reach into the vending machine to get my change out’. I see the value in ORMs, but I also see where Abe is coming from in this article. I think the sweet spot for an ORM is when you’re just getting started making apps and you want to minimize how many technologies you need to learn to get there. I certainly learned SQL over a slow, productive period while utilizing its features from the warm embrace of Active Record. Stick around to the end of the article where he reveals the anti-ORM he’s working on to solve some of these problems.

read more

Silas Reinagel silasreinagel.com

Well-composed software has a distinct shape

Silas Reinagel: The difference between great code and terrible code is how well structured the problem solution is. This article gives a clear-as-day way to visualize how well structured code is, in addition to explaining the concepts that result in those shapes. I’ve long used the squint test as a first step toward evaluating a piece of code. This lines up with what Silas is preaching in this solid piece on software composition.

read more

Yaron Wittenstein Medium

The importance of unlearning

Yaron Wittenstein: The world of software is constantly changing at a very fast pace. Yesterday’s axioms might be tomorrow’s anti-patterns. Newborn technologies rise to popularity only to become obsolete sooner than expected and hardware advancements make things that were considered science-fiction a few years ago possible. The only certainty is that we don’t know what the future will bring us. One mantra in this industry is always-be-learning. A message we don’t communicate well enough, however, is how you also have to be willing to let go of once-useful-but-now-limiting knowledge.

read more

Chris Coyier CSS-Tricks

Should a website work without JavaScript?

Chris Coyier can’t help but chime in after listening to our recent debate episode of JS Party. I enjoyed all the stumbling around the terminology of “web apps” and “web sites” (web things!). This is such a weird one. It’s so easy to picture the difference in your head: it’s like facebook versus a blog! But when you start trying to define it exactly, it gets really murky really quickly and the distinction loses any value, if it had any to start with. Here’s more on that. Chris has a lot of great insights here. Whether you agree or disagree, I think we can all get on board with one thing: we make web things!

read more

Practices github.com

Natural Language Processing best practices & examples

The goal of this repository is to build a comprehensive set of tools and examples that leverage recent advances in NLP algorithms, neural architectures, and distributed machine learning systems. The content is based on our past and potential future engagements with customers as well as collaboration with partners, researchers, and the open source community.

read more

Brent Simmons inessential.com

Brent Simmons on following through

If you’re an app maker, it might seem like your goal is to get to release day. Get the app done, make it available, publish an announcement, and then get back to coding. Let the world do what it’s going to do. But that’s not going to maximize your chances for a good release. You need to follow through — you need to keep going. Brent’s list of things you might do in the wake of a big release is worth tucking away for the day after your next one.

read more

Stephanie Morillo stephaniemorillo.co

Naming things is hard but we still have to try

Stephanie Morillo: Naming things is hard because languages are hard, and no two people have the same exact understanding of the same word. But we have to ascribe names and labels to things all the time… This post seeks to help readers understand why labeling is so difficult. There’s a bit of linguistics, library science, and information architecture thrown in for good measure, but the point is this: language isn’t static and the same goes for the websites, databases, and other objects we create and build.

read more

Lazarus Lazaridis iridakos.com

Composing better emails

Lazarus Lazaridis: Email communication is not my favorite but since I can’t avoid it, I am trying to compose messages in a way that I think it makes it easier for both me and the recipient: to quickly address what is being communicated avoid misunderstandings save time There are some really solid tips in this post. I’ll add another one: If your email contains multiple questions and/or requests*, number them. In my experience this greatly improves the odds that they each get addressed in the reply. When I don’t number them I usually only get the first or last one addressed. *let’s please stop referring to requests as “asks”, kthxbai

read more

Jay Freestone browserlondon.com

Should we still be selling responsive web design?

The term ‘responsive web design’ has been a mainstay in the world of digital development for many years. Go to any early-stage client meeting and you’ll almost always get asked to ‘make sure it works on mobile’. The standard response to this has generally been, ‘don’t worry, we’ll build it responsive’, but is this response out of date?

read more

Gergely Orosz blog.pragmaticengineer.com

Developers mentoring other developers

What, exactly, is mentoring? How does it work? Better yet, how does it work well? In this post Gergely Orosz, Engineering Manager at Uber, shares his perspective and the practices he’s seen work well. Mentorship has been the best things that’s sped up my growth and others engineers around me. This post discusses mentorship practices that work well engineer-to-engineer. The practices come from my own experience, observations I’ve made people mentoring each other and from conversations I’ve had with half a dozen mentors in my network and on Coding Coach.

read more

Joel Marcey Medium

Hello, I am a Developer Advocate

Joel Marcey shares his story and some background on what a developer advocate is and how to be success as a developer advocate. I am a believer in the pop-culture version of Occam’s razor, or the law of simplicity, where the simplest explanation is usually the right one. A developer advocate is exactly what its title implies — an advocate for developers. A successful developer advocate can go both deep and broad. They can own a technology stack but also run programs that span an entire open source program office… A successful developer advocate is able to quickly ramp up on new technologies, sometimes with no background in the space previously, and be able to understand how those technologies may fit into the overall open source ecosystem.

read more

freeCodeCamp Icon freeCodeCamp

Focus and deep work — secret weapons to becoming a 10x developer

Focus was the topic of this and this episode of Founders Talk, but from a different angle than presented in this post from Bar Franek on freeCodeCamp. It doesn’t matter if you’re working on a side hustle or if you’re a junior developer wanting to get noticed and promoted. It doesn’t matter if you’re a lead developer looking for a change of pace, from a corporate gig to a start-up or the other way around. It doesn’t matter if you’re jobless out of college. As long as you’re a programmer, no skill is more important to your success than focused, deep work.

read more

Marcy Sutton marcysutton.com

Links or buttons?

To button or not to button…the button element is “actually really cool”… Something that comes up again and again in front-end accessibility is the issue of links versus buttons. You know, the HTML elements that open links in new windows or submit forms? In JavaScript web applications, it seems we’re still confused about which element to choose for user interaction. To try and clarify the haziness, I’ll define use cases for links and buttons in client-rendered applications and help you make better UI decisions, from design to development.

read more

Julia Evans jvns.ca

Not getting your work recognized? Brag about it.

Most people are modest about their contributions in the workplace. We also forget how important our contributions are. Then, when it comes time for recognition, you’ve forgotten, others didn’t notice because they don’t understand all the details and moving parts, and work just moves on. What do you do if/when your work goes unnoticed? Here’s what Julia Evans suggests… Instead of trying to remember everything you did with your brain, maintain a “brag document” that lists everything so you can refer to it when you get to performance review season! This is a pretty common tactic – when I started doing this I mentioned it to more experienced people and they were like “oh yeah, I’ve been doing that for a long time, it really helps”. Where I work we call this a “brag document” but I’ve heard other names for the same concept like “hype document” or “list of stuff I did” :). BONUS — Julia included a basic template for a brag document at the end of the post.

read more

Erik Kennedy learnui.design

4 rules for intuitive UX

Erik Kennedy is back to give developers (and other folks who aren’t steeped in UX) some actionable advice on how to make interfaces more usable. This is my advice on improving the UX of your designs WITHOUT hours of user research sessions, paper prototyping playtime, or any other trendy UX buzzwords. When I started as a professional UX designer, I was shocked how many times my clients would hand me the initial wireframes (or the living, breathing, in-browser MVP) and there’d be completely obvious UX mistakes all over them. I’m not talking about things you need hours of research and A/B testing to discover. I’m talking, like, dead simple mistakes.

read more

The Changelog The Changelog #357

Shaping, betting, and building

Ryan Singer, head of Product Strategy at Basecamp, joined the show to talk about their newest book — Shape Up: Stop running in circles and ship work that matters. It’s written by Ryan himself and you can read it right now for free online at Basecamp.com/shapeup. We talked about the back story of the book, how the methodology for Shape Up developed from within at Basecamp, the principles and methodologies of Shape Up, how teams of varying sizes can implement Shape Up. Ryan even shared a special invitation to our listeners near the end of the show to his live and in-person Shape Up workshop on August 28th in Detroit, Michigan.

read more

Marianne Bellotti Medium

All the best engineering advice I stole from non-technical people

Marianne Bellotti shares five pieces of advice she’s taken from folks in other walks of life (NSA agents, therapists, etc) and how she’s applied that in the software world. My favorite one is “Thinking is also work”. On this topic, Marianne notes: On a personal level it gave me permission to take time when I needed time. Why should I feel guilty about leaving the office to go on a walk? Thinking is also work. I can’t emphasize enough how important it is for us to get away from our computers a few times a day. Many of my best decisions and moments of inspiration have come while on a walk, a bike ride, or yes, while taking a shower! 🚿

read more

The Changelog The Changelog #356

Observability is for your unknown unknowns

Christine Yen (co-founder and CEO of Honeycomb) joined the show to talk about her upcoming talk at Strange Loop titled “Observability: Superpowers for Developers.” We talk practically about observability and how it delivers on these superpowers. We also cover the biggest hurdles to observability, the cultural shifts needed in teams to implement observability, and even the gains the entire organization can enjoy when you deliver high-quality code and you’re able to respond to system failure with resilience.

read more

0:00 / 0:00