Practices Icon


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

GitLab Blog Icon GitLab Blog

How to recognize burnout (and how to prevent it)

Erica Lindberg, writes on the GitLab blog about preventing burnout: Set clear boundaries between work and home — I'm trying to limit how many days I allow myself to work over eight hours by either scheduling other activities in the evening with friends or my partner (it works better when you've committed to someone so they can help hold you accountable. These things can be anything from rock climbing to dinner or watching a movie) or simply blocking out my calendar and setting reminders for when it's time to shut off. And when it is time to shut off I'm come up with a "ritual" of shutting down my computer, turning off my keyboard, monitor, and light in my office – this makes it harder to come back to "just finish up one last thing" I really needed to be reminded of this. It's a shame when you know what to do, but you choose not to, and allow yourself to creep closer to burnout.

logged by @adamstac 2018-03-23T22:14:37.873694Z permalink #culture #practices

Yegor Bugayenko

Fluent interfaces are bad for maintainability

Yegor Bugayenko: Fluent interface, first coined as a term by Martin Fowler, is a very convenient way of communicating with objects in OOP. It makes their facades easier to use and understand. However, it ruins their internal design, making them more difficult to maintain. A few words were said about that by Marco Pivetta in his blog post Fluent Interfaces are Evil; now I will add my few cents. Yegor uses his own HTTP library as an example where the interface designed is fluent (which looks nice and readable to use) and shows how that design goal made the internal code a mess. My gut tells me it's worth the trade-off to provide a better user experience, but Yegor's real-life experience punches me right in the gut: Fluent interfaces are perfect for their users... However, the damage they cause to object design is the price, which is too high. He suggests decorators and smart objects as an alternative. Lots to ponder here, and the conversation going on in the comments is lively as well. 👌

logged by @jerodsanto 2018-03-19T13:52:00.10850Z permalink #oop #practices

Dimitri Fontaine

Database modeling anti-patterns 🙅‍♀️

Dimitri Fontaine shares 3 classic data-modeling anti-patterns. The UUID section lacks strong argumentation, but the real gem in this article is his advice at the end. A snippet: My advice is to always normalize your database model first, and then only fix the problems you have with that when you actually have them. Well except in those 3% of cases where really, really, it should be done in the design phase of the project. It’s quite hard to recognize those 3% though, and that ability is hard gained with experience. Experience is the ultimate teacher.

logged by @jerodsanto 2018-03-18T22:24:00.008452Z permalink #database #practices

Medium Icon Medium

You’re not lazy

The subtitle here should have been “We’re all very !#$@%#$ afraid”. The reason I often hold back from doing something or when I self-sabotage a goal — the real reason is because I’m afraid of what will happen if this thing is actually successful??! Then, I’ll have to actually do it. 😱 John Gorman, writes for Personal Growth on Medium: Fear doesn’t manifest itself like you think, because often times we don’t give it the chance to. Fear isn’t always the sweaty palms that stop us cold in a job interview — fear is generally what prevents us from applying in the first place. Spend 8 minutes and read this.

logged by @adamstac 2018-03-16T17:29:15.836089Z permalink #practices

GitLab Blog Icon GitLab Blog

How working at GitLab has changed my view on work and life

Hazel Yang, on the GitLab blog shares insights about her last two years working at GitLab: Show gratitude Learn from failure Trust your team and grow with them Befriend managers and colleagues Embrace diversity I'm a HUGE fan of the concept of a "retrospective" which is most known by developers as a practice of agile software development. It is important to look back and review what's going well, what's not going well, and what needs to change or be stopped all together. This post is a product of that type of discipline.

logged by @adamstac 2018-03-15T20:24:37.434906Z permalink #culture #practices

Nikita Sobolev DEV

I am a mediocre developer

Nikita Sobolev outlines why they're a self-described "mediocre developer" and how they survive in such a state. What follows is a bunch of excellent advice on practical steps toward success as a developer. Ironically, Nikita's self-professed mediocrity and clear path toward defeating it makes them an outstanding developer in my eyes. 🤩 Go and do likewise.

logged by @jerodsanto 2018-03-15T14:41:00.051419Z permalink #practices #culture

Stephanie Morillo

Things to keep in mind when building an engineering blog

Stephanie Morillo drops some wisdom she gained running the Digital Ocean blog for the past year: Teams need buy in from the engineering org, a primary owner for all things blog related, a regular publishing cadence, ongoing conversations, flexibility, cross-functional communication, and open dialogue with readers to get the most out of their blog efforts. Getting buy-in can be the hardest part. I have a hard time convincing myself to blog, let alone other people.

logged by @jerodsanto 2018-03-09T22:49:00.008176Z permalink #blogging #practices

YouTube Icon YouTube

"You have to be run by ideas not hierarchy..." - Steve Jobs

Steve Jobs, in his last interview with Walt Mossberg and Kara Swisher at the All Things Digital's D8 Conference in 2010. Steve died a year later. We're organized like a start up. We're the biggest startup on the planet. There's tremendous teamwork at the top of the company, which filters down to tremendous teamwork throughout the company. Teamwork is dependent on trusting the other folks to come through with their part without watching them all the time, but trusting they're going to come through with their parts. That's what we do really well. If you wanna hire great people and have them stay working for you, you have to let them make a lot of decisions and you have to be run by ideas not hierarchy. The best ideas have to win, otherwise good people don't stay. This interview has many great highlights, but this part is some of my favorite advice Steve has ever given about how to run a company. We strive to achieve this at Changelog. Here's a link to the full video, and the same but deep linked to the part quoted in this post.

logged by @adamstac 2018-03-04T06:32:26.687751Z permalink #practices

Alex Sexton

The 15 commandments of front-end performance

Alex Sexton, on his personal blog: This list is the product of many years of experience in the front-end web development field. I maintain this list as a reminder to myself to always follow best practices, and to not compromise on performance, even if I’m in a time crunch. I read it before I start any project, and share it with my team at work (sometimes we joke and call them “codemandments”) so we can all be on the same page and do our part to keep the web fast. He goes on to say "feel free to fork this for your own use," so use this liberally. Some of my favorites: I will use SVGs instead of JPGs, wherever possible. I will resist the urge to use window.alert to inform visitors that there’s a Facebook group for cool friends and if they wanna join it, that’s fine, it only takes a few clicks. 😂

logged by @adamstac 2018-03-02T21:03:07.693884Z permalink #front-end #practices

Ben Balter

Why you probably shouldn’t add a CLA to your open source project

The TLDR: Contributor license agreements (a “nice to have” for many corporate-backed open source projects) create a contribution-hostile developer experience, require significant administrative overhead, shift legal blame to the party least equipped to defend against it, and are unnecessary given modern development tools. Click through to read each of these points explained in great detail.

logged by @jerodsanto 2018-02-28T15:27:00.012075Z permalink #practices

Practices Icon

Why do programmers start counting at zero?

Mike Hoye dives deep to answer this question: By now your peripheral vision should have convinced you that this is a long article... He's right. This piece looked so long that I kept it open in a tab (the original Instapaper) for a couple of weeks before reading it. But it's not so bad! And the topic is fascinating: starting at 1 is not an unreasonable position at all; to a typical human thinking about the zeroth element of an array doesn’t make any more sense than trying to catch the zeroth bus that comes by, but we’ve clearly ended up here somehow. So what’s the story there? My head canon on the topic treats zero-indexing in terms of offsets. How much of an offset do you need to reach the first entry in the array? Zero. How much for the second? One. Turns out, nope that's not why!

logged by @jerodsanto 2018-02-26T14:56:00.008238Z permalink #learn #practices

Practices Icon

What does a developer advocate do?

Lorna Jane Mitchell, on the role of a developer advocate: The less-visible part of the role is probably the most technical part. People rarely think of the gregarious advocates they see on stage or tweeting as being technical but we are, probably more than you expected. I write sample code and internal tools, but better than that: it's my business to wade in and improve anything that would make life easier for developers. An advocate is just that, someone who acts on another's behalf — a role that requires a variety of skills: The job requires a really weird mix of skills, and like most advocates I'm endlessly delighted to find that there's a job that combines such a great combination of stuff I like to do! The role varies a lot between jobs, and also between weeks — it's a little bit of everything.

logged by @adamstac 2018-02-15T15:15:38.117178Z permalink #practices

Medium Icon Medium

What I wish I knew when I became CTO

From David Mack, CTO and co-founder of SketchDeck: You can accumulate responsibility faster than you can learn how to harness it. I now appreciate that the infrastructure, frameworks, and languages you choose will stick with you for a really long time. Only hire when you feel you’re completely desperate for the role. Hire to keep up with growth, not to generate it. I really appreciated David's thoughts on hiring.

logged by @adamstac 2018-02-15T02:25:52.857259Z permalink #practices

Matt Steele

The neverending side project

Matt Steele, ruminating on the side project that he's been hacking on since 2011: A long-lived side project gives you the chance to confront your old habits and see how far you've progressed. Over the years, he's rewritten the Super Bowl Squares app 5 different times. One of his findings: A long-lived side project also gives you breathing room to ask how much stock to put into trends. My original jQuery app still loads faster, has 60% less code, and (to my mind) is more understandable than my latest version built atop Angular 5. Have I actually made things better? Have we as an industry? Good question!

logged by @jerodsanto 2018-02-13T17:01:00.009558Z permalink #practices

CSS Icon

Everything easy is hard again

This is a long, nuanced piece about progress in web-building technologies and practices. It's written from a designer's perspective, but many of the themes ring true to my developer's brain. I wonder if I have twenty years of experience making websites, or if it is really five years of experience, repeated four times. If you’ve been working in the technology industry a while, please tell me this sounds familiar to you. The primary example cited is how we answer the simple question, "How do I put two things next to each other?" The status quo has changed (tables -> floats -> Flexbox -> CSS grids), but to what advantage? A few of his points feel a bit like looking back at the "good 'ole days" through rose colored glasses, but his case is mostly well-reasoned and powerful. the foundations are now sufficiently complicated enough on their own that it seems foolish to go add more optional complexity on top of it. I’ve kept my examples to the most basic of web implementations, and I haven’t touched on Javascript, animation, libraries, frameworks, pre-processors, package managers, automation, testing, or deployment. Whew. Whew, indeed! The breadth and depth of knowledge required to feel competent in today's web ecosystem is probably why we spend so much time dealing with imposter syndrome in this industry.

logged by @jerodsanto 2018-02-12T14:19:00.08510Z permalink #design #css #practices

Rico Sta. Cruz Avatar The Changelog #283

Devhints - TL;DR for Developer Documentation

Rico Sta. Cruz joined us to talk about his project Devhints — cheatsheets for developers! There are more than 365 cheatsheets you can contribute to and it's open source. We talked about the design, technical implementation, community, and alternate interfaces (CLI). We also covered RSJS, RSCSS, and Docpress. You have to sell what it is you're building in your documentation. It's not just describing what it is and how to use it. It's about telling interesting stories. — Rico Sta. Cruz

logged by @adamstac 2018-02-09T23:18:08.927265Z permalink #practices #javascript #css

Kelsey Hightower

No Code

Reminds me of madrobby/vapor.js. No code is the best way to write secure and reliable applications. Write nothing; deploy nowhere. Go back in time and listen to The Changelog #39 to hear about Vapor.js.

logged by @adamstac 2018-02-07T16:30:51.346911Z permalink #practices

Practices Icon

Why write postmortems?

Postmortems are a healthy exercise to do after an incident to learn the specifics of why it happened and what needs to be done to prevent it from happening again. A good report captures the risks of current services, and helps Product and Engineering to more proactively prioritize work on services. Someone from outside your team should be able to read your postmortem report and answer these five questions...

logged by @adamstac 2018-02-01T04:16:00.009523Z permalink #practices #ops

TODO Group Icon TODO Group

A guide to shutting down an open source project

The TODO Group published a set of guides last year focused on open source program management. This year, they kicked things off with an initial guide about how your org and team can plan for the day when you're ready to end or move away from an open source project. This guide covers the gamut of concerns around shutting things down: Why life cycle planning is important What does a dead open source project look like? Trouble signs to watch for Why plan for the end of a project before you even launch it? Protecting your company’s reputation Of course, all of the TODO Group guides are open source on GitHub. We talked about the TODO Group with Will Norris from Google on The Changelog #245.

logged by @adamstac 2018-01-30T05:51:44.969834Z permalink #practices

Practices Icon


This is an incredibly insightful piece the difference between popularity and quality in software development. In software development, a lot of people pick the most popular tool that can solve a given problem. Popularity is measurable: you can check the number of downloads, the number of stars, the questions and answers all over the web. Quality, on the other hand, is hard to measure... An anecdote of a CTO trying to navigate tool selection with his development team is provided, and while his choice is out of the ordinary, the response from the peanut gallery is not. Read the whole thing (it's short), but here's a snippet of the author's takeaway: we should be extremely cautious about taking what is popular for what is good, and conversely we should not disregard something just because it didn't gather enough stars. This reminds me of the excellent conversation we had with Ozan Onay on episode #260 of The Changelog, where he encouraged developers everywhere to DYOR.

logged by @jerodsanto 2018-01-29T15:52:00.010578Z permalink #practices
0:00 / 0:00