Practices Icon

Practices

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

Ives van Hoorne Medium

VSCode themes in CodeSandbox?

Ives van Hoorne writes on Medium: Personalizing color schemes is one of the most important things to have in an code editor. CodeSandbox didn’t have any way to personalize colors in the editor since release, but I’m happy to announce that we do now. The best part is that we were able to reuse a big chunk of logic from VSCode directly and also support any VSCode theme natively in CodeSandbox!

read more...

Segment Icon Segment

Segment says goodbye microservices

This is Segment's story from monorepo to microservies back to monorepo — "from 100s of problem children to 1 superstar child." Software Engineer Alexandra Noonan writes on the Segment Engineering blog: As time went on, we added over 50 new destinations, and that meant 50 new repos. To ease the burden of developing and maintaining these codebases, we created shared libraries to make common transforms and functionality ... Over time, the great benefit we once had of reduced customization between each destination codebase started to reverse. Eventually, all of them were using different versions of these shared libraries. The woes of operational overhead with each expansion into more microservices. The number of destinations continued to grow rapidly, with the team adding three destinations per month on average, which meant more repos, more queues, and more services. With our microservice architecture, our operational overhead increased linearly with each added destination. Therefore, we decided to take a step back and rethink the entire pipeline. One of the original motivations for separating each destination codebase into its own repo was to isolate test failures. However, it turned out this was a false advantage. With destinations separated into their own repos, there was little motivation to clean up failing tests. I'd love to dig into this story more on The Changelog with the team behind this transition back to a monolith and discuss the deeper details of their lessons learned.

read more...

Gabriel Peal Medium

React Native at Airbnb

This epic four part series from the Airbnb engineering blog showcases how React Native was used at Airbnb to enable their teams to move quickly and maintain a great developer experience. However, in the end, they decided to sunset React Native and focus on native — but their journey to that conclusion is well worth a read. Part 4: Sunsetting React Native — Although many teams relied on React Native and had planned on using it for the foreseeable future, we were ultimately unable to meet our original goals. In addition, there were a number of technical and organizational challenges that we were unable to overcome that would have made continuing to invest in React Native a challenge. As a result, moving forward, we are sunsetting React Native at Airbnb and reinvesting all of our efforts back into native. It's not all bad though. 63% of their engineers would have chosen React Native again given the chance and 74% would consider React Native for a new project. Gabriel went on to say: React Native is progressing faster than ever. There have been over 2,500 commits in the last year and Facebook just announced that they are addressing some of the technical challenges we faced head-on. Even if we will no longer be investing in React Native, we’re excited to continue following its developments. For a different perspective read Should we use React Native? — a follow-up post to this four part series.

read more...

Peter Steinberger pspdfkit.com

How to use Slack and not go crazy

Read this for the sidebar management tips alone! Wow, I had no idea how cluttered my sidebar was until I followed Peter's guidance from this post. Declutter your sidebar by hiding all channels that don’t contain unread messages and are not starred. You still won’t miss anything, as they pop up if there’s chatter, and you can always use ⌘-T to open the Jump menu. It’s amazing how much better it feels if there aren’t 50 channels you need to scroll through all the time. This post was extracted from Peter's talk Effective Remote Communication.

read more...

Ken Wheeler medium.com

A bitter guide to open source

Ken Wheeler (Director of open source at Formidable) shared some pretty helpful words to get you excited about open source and also how to launch your first project. Nothing makes your repo look more legit than badges. Too many badges looks memey as fuck, but if you include useful ones, its a stamp of legitimacy. It shows you care. Things like npm version, test status, coverage numbers. It’s nice flair. Also, Markdown supports raw HTML, so you can make your repo header look nice. Center things, add a quote, jazz it up a bit. Ken even shared his thoughts on the best time to launch. My recommendation is very specific. Release at 12pm EST on a Monday. It’s the end of Europes day, New York’s lunch break and San Franciscos hour in the morning before anything gets done.

read more...

Mike Cohn mountaingoatsoftware.com

10 practices to be a better Scrum Master

One of my favorite jobs in software was when I was a Product Manager for a non-profit startup. In that role I was able to impact and touch pretty much any part of the business I wanted to, it was almost like being an entrepreneur, but doing so from within an already formed company. I also led our agile software development as Scrum Master — it was awesome. I wish I had this list of advice back then. Mike Cohn writes on the Mountain Goat Software blog: Never commit the team to anything without consulting them first — As Scrum Master, you do not have the authority to accept change requests (no matter how small) on behalf of the team. Even if you are absolutely positive that the team can fulfill a request. Always say, “I need to run this by the team before we can say yes.” And certainly don’t commit the team to deadlines, deliverables, or anything else without first talking to team members. You may not need to talk to the whole team--plenty of teams will allow some or all members to say, “Yeah, we can do that” without a whole-team meeting. But it’s still their decision, not yours. This is number 1 on the list, because you should never get this one wrong.

read more...

Casper Beyer Medium

Is the internet at the mercy of a handful of developers?

In this post from Casper Beyer titled The Node.js Ecosystem Is Chaotic and Insecure, he cites examples like left-pad, is-odd, is-number — and goes on to say the way to be responsible with dependencies is... ...don’t trust package managers, every dependency is written by some random developer somewhere in the world and is a potential attack vector. ... Is this being too paranoid? Perhaps, or maybe it’s the healthy amount considering the massive reach these trivial packages can have. While this focuses on Node.js, the lessons learned apply anywhere you have dependencies in your code.

read more...

André Staltz staltz.com

Your IDE as a presentation tool

André Staltz: I’ve just given my third programming talk where I use only my IDE (integrated development environment) for live coding and no other presentation tool. I noticed the audiences were very pleased with these talks, and I think it’s correlated to using an IDE and not a slides program. If you've ever watched one of André's talks, you know he gives good talks regardless of whether or not he's using an IDE. But he makes a good case for their use in general and goes in to great detail* on how to do it well. *even explaining each individual editor setting and why they were selected

read more...

Zach Holman zachholman.com

UTC is enough for everyone, right?

Programming around time is the bane of pretty much every programmer's existence. UTC works most of the time, but still has its flaws. Zach Holman writes on his blog: Programming time, dates, timezones, recurring events, leap seconds... everything is pretty terrible. The common refrain in the industry is Just use UTC! Just use UTC! And that's correct...sort of. But if you're stuck building software that deals with time, there's so much more to consider. It's time...to talk about time. Zach includes a lot of time-related puns and whole lot of wisdom about programming time.

read more...

Medium Icon Medium

We do Scrum but…our management doesn’t.

Bummer. I've been there. It's so tough to make iterative change to software when those who are "in charge" of what you do everyday keeps interrupting or changing the rules to the game. Sjoerd Nijland writes on the Serious Scrum blog: As Scrum is a framework for developing, delivering, and sustaining complex products, and, if your management isn’t actively engaged in this exercise, it indeed may not make immediate sense for them to adopt the framework. Scrum could thus be perceived to be for developers only. Or perhaps Scrum was introduced by and is still contained to the development organization. In this case it may make sense to talk about the definition of ‘Product’. Would it make sense for the Management Team, to consider the organization itself as a product? If your team does Scrum, you should 100% read this.

read more...

Hongli Lai Phusion Blog

Who’s responsible for the software we build?

If software is eating the world, who is writing that software? You are. Hongli Lai, Co-founder & CTO of Phusion gave a talk at his local Amsterdam.rb meetup and shared his thoughts on the impending deadline of the EU General Data Protection Regulation (GDPR) and the impact of socially unaware software that's eating our world. ...I feel more and more convinced we (as Phusion and as ‘builders of the web’) have a responsibility to provide a framework for thinking about the ethical implication of our creations. Hongli continues: We've seen companies suffer recently for a lack of that social responsibility (data breaches at Equifax, Facebook, Uber, etc). Public outrage was strong but also burned out quickly as the news cycled. For a while, the same quick fizzle seemed to be happening with the Facebook and Cambridge Analytica scandal. It's up to us to fight back. That doesn't mean go on twitter and rant, but to actually go an do something. Give a talk in your local area to your developer communities to create with social responsibility in mind.

read more...

Yegor Bugayenko yegor256.com

How to be lazy and stay calm

Laziness is one of the three great virtues of a programmer (laziness, impatience, and hubris) Larry Wall talked about in Programming Perl. The "deep thinking," as they call it, which is always required before even a small issue can be resolved, seriously turns me away from programming. Or did turn me away. Until I started to think differently and encourage myself to be lazy. Here is how. Iteration! It's so freeing to operate on the basis of iteration — knowing that today's version is shipping with flaws that can only be resolved through the feedback loop. In this case, incremental is an alias of iteration. Software development is perfect territory for cutting corners, being lazy and remaining calm, because our work is often discrete and can be very incremental.

read more...

Evelyn Van Kelle O'Reilly Media

Strong feedback loops make strong software teams

I'm a huge fan of well designed feedback loops. In software creation, feedback loops prove to be one of the most important, often overlooked, artifacts of the development lifecycle. Evelyn Van Kelle writes on the O'Reilly Ideas blog: There is a false dichotomy between full automation and human intervention. Successful quality control combines tool-based measurement with manual review and discussion. At the end of the day, the most effective feedback loops are a mixture of daily best practices, automation, tools, and human intervention.

read more...

 Itamar Turner-Trauring codewithoutrules.com

You are not your tools

Itamar hits the nail on the head: If you think of yourself as a Python programmer, if you identify yourself as an Emacs user, if you know you’re better than those vim-loving Ruby programmers: you’re doing yourself a disservice. You’re a worse programmer for it, and you’re harming your career. I've been preaching the gospel of generalization for many years. This industry moves fast. Today's new hotness is tomorrow's old and busted. Learn specific skills, yes. But always keep yourself above the fray. I am not a Rails Developer. I am not an Elixir Guy. Heck, I don't even consider myself a web developer. I solve problems; sometimes by writing software. Back to Itamar: The technologies you use, the tools you build with, are just that: tools. Learn to use them, and learn to use them well. But always remember that those tools are there to serve you, you are not there to serve your tools.

read more...

Floor DrEES Phusion Blog

Make your project pull request ready

Do you wish you weren’t the only person slaving away on your open source project? Find out how to make your project pull request ready in this guide from our friends at Phusion. Floor Drees, writes on the Phusion blog: Newcomers to your project will turn to your issue tracker and look at (merged) pull requests, discussion forums, mailing lists or chat channels to form an idea of what your project is like and how and where they can best contribute. Optimizing these channels for on-boarding contributors will set you up for success.

read more...

Yegor Bugayenko yegor256.com

How I test my Java classes for thread-safety

Yegor Bugayenko: Thread-safety is an important quality of classes in languages/platforms like Java, where we frequently share objects between threads. The issues caused by lack of thread-safety are very difficult to debug, since they are sporadic and almost impossible to reproduce on purpose. How do you test your objects to make sure they are thread-safe? Here is how I'm doing it. Great details on a particularly difficult aspect of testing. ✨

read more...

Practices Icon rachelbythebay.com

Look for the duct tape

Rachel Kroll with some sage advice on how to find interesting things to work on: In concrete terms, go around and find out what kind of little one-off tools people have designed. Talk to them and hear their stories. Look in their personal bin directories. Take notes and look for patterns. See if anything stands out, or if anything particularly compelling grabs you during the interviews.

read more...

GitLab Icon GitLab

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.

read more...

Yegor Bugayenko yegor256.com

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. 👌

read more...

Dimitri Fontaine tapoueh.org

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.

read more...

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.

read more...

GitLab Icon GitLab

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.

read more...
0:00 / 0:00