Practices Icon

Practices

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

Founders Talk Founders Talk #60

Leading data-driven software teams and products

For the final show of 2018 I’m talking with Travis Kimmel, the CEO of GitPrime. Travis has spent years as an engineering manager. Travis’s mission at GitPrime is to bring crystal clear visibility into the software development process and bridge the communication gap between engineering and stakeholders. This communication gap is often an ongoing plague in product development lifecycle. We talked through focus, tech debt, leading teams, predictability, and more.

read more

Aaron Turner Medium

WebAssembly vs. ES6 — benchmark battle!

Aaron Turner (UXE at Google) says “WebAssembly is fast” and has conducted a real-world benchmark between WebAssembly and ES6 to showcase Wasm’s performance on different browsers, devices, and cores. …this benchmark will be utilizing the WasmBoy benchmarking tool (source code). The benchmark features three different cores as of today. AssemblyScript (WebAssembly built with the AssemblyScript compiler), JavaScript (ESNext output by the TypeScript compiler), and the previous JavaScript core except run through Google’s Closure Compiler…

read more

Charity Majors honeycomb.io

How much should my observability stack cost?

I love the way Charity Majors, CEO of Honeycomb.io, opens up this post… What should one pay for observability? How much observability is enough? How much is too much, or is there such a thing? Is it better to pay for one product that claims (dubiously) to do everything, or twenty products that are each optimized to do a different part of the problem super well? It’s almost enough to make a busy engineer say “Screw it, I’m spinning up Nagios”. (Hey, I said almost.)

read more

Practices simplabs.com

How simplabs maintains a large number of open source projects

In this blog post we will introduce you to some of out internal best practices we have developed or discovered to simplify and speed up working on open-source and other projects. There’s nothing revolutionary in here for those experienced in open source maintenance, but it’s a good rundown nonetheless. It’s also interesting to see how many teams are now using (and recommending) dependency update services such as dependabot and Greenkeeper.

read more

Yegor Bugayenko yegor256.com

You can do better

Yegor Bugayenko: Now here is a simple, plain list of recommendations for you: what you should do if you want to be a more successful programmer. Not a better algorithm designer, even though that’s important. Not a funnier team player, even though that’s also important. But a more successful software engineer, both financially and socially. Of the 14 recommendations, I’m happy to report that I regularly engage in 10 of them! The only one that I’m diametrically opposed to is Earn Certificates. No thanks! What do you think of Yegor’s recommendations?

read more

 Itamar Turner-Trauring codewithoutrules.com

Enthusiasts vs. Pragmatists

Do you love programming for its own sake, or do you just program for the outcomes it enables? Depending on which describes you best you will face different problems in your career as a software developer. Enthusiasts code out of love. If you’re an enthusiast you’d write software just for fun, but one day you discovered your hobby could also be your career, and now you get paid to do what you love. Pragmatists may enjoy coding, but they do it for the outcomes. If you’re a pragmatist, you write software because it’s a good career, or for what it enables you to do and build. Which is your camp and why?

read more

Eugen Kiss blog.usejournal.com

Lean testing or why unit tests are worse than you think

This is a spectacularly thoughtful and insightful piece by Eugen Kiss on testing: Different kinds of tests have different costs and benefits. You have finite resources to distribute into testing. You want to get the most out of your tests, so use the most economic testing approach. He goes on to describe why he believes that integration tests provide better ROI than unit tests and end-to-end tests. Then he turns his aim on unit tests in particular: There is the claim that making your code unit-testable will improve its quality. Many arguments and some empirical evidence in favor of that claim exist so I will put light on the other side… Unit tests ossify the internal structure of the code. Click through to read his whole argument, but I will say in my experience unit tests only ossify the structure when I do them poorly. In other words, the better I get at unit testing, the more useful they become. In light of that, Eugen’s big takeaway at the end might be 💯 on point: If you desire clear, albeit unnuanced, instructions, here is what you should do: Use a typed language. Focus on integration and end-to-end tests. Use unit tests only where they make sense (e.g. pure algorithmic code with complex corner cases). Be economic. Be lean.

read more

Daniel Stenberg daniel.haxx.se

QUIC will officially become HTTP/3

We recently talked with Daniel Stenberg about HTTP/2 and QUIC, so this news comes with little surprise looking back on that conversation with hindsight. The protocol that’s been called HTTP-over-QUIC for quite some time has now changed name and will officially become HTTP/3. This was triggered by this original suggestion by Mark Nottingham. On November 7, 2018 Dmitri of Litespeed announced that they and Facebook had successfully done the first interop ever between two HTTP/3 implementations. Mike Bihop’s follow-up presentation in the HTTPbis session on the topic can be seen here. The consensus in the end of that meeting said the new name is HTTP/3!

read more

ZEIT Icon ZEIT

Now 2.0

My biggest take away from this epic announcement from ZEIT? The support of the majestic monorepo! …Now 2.0 enables what we will call The Majestic Monorepo, inspired by a similarly named essay by DHH, creator of Ruby on Rails (The Majestic Monolith). We don’t agree that you should be orchestrating a big server abstraction (a monolith), but we believe you should be able to collocate your APIs and your business logic in a single place, with a cohesive deployment story. It looks, feels and deploys like a monolith, with none of its downsides. …but there is SO MUCH MORE to this announcement. Also, we talked a bit about David’s idea of The Majestic Monolith on The Changelog #286.

read more

Noa Gruman blog.streamroot.io

Implementing a multi-CDN strategy? Here's everything you need to know.

There’s some seriously interesting thoughts shared here for building out a multi-CDN strategy. Having had issues with how to best use and leverage a CDN to get the best performance benefits, I can see how having a multi-CDN implementation would allow us to choose the right CDN for a given region of the world, as well as a whole host of other options based on things like cost, performance, and of course redundancy for when things go wrong. Murphy’s law, right? This summer, the 2018 World Cup set an all-time streaming record – tripling its own 2014 record – with over 22 Tbps measured by Akamai at peak, but the event wasn’t smooth sailing for everyone. In a highly competitive market, and in an age where streaming failures make headlines, redundancy and quality of experience have never been more crucial for content publishers. Drop a comment below if there are other resources out there on this subject that we should check out.

read more

Medium Icon Medium

Complexity is creepy: It's never just "one more thing."

The fight against complexity is analogous to the fight against contentment. Find contentment and you will find yourself at the end of a project. Hint: we will never be fully content. We live in a dynamic world of infinite, and never-ending change. There will always be a critique to offer. Perfection is an illusion. We’ve all worked on projects that never seem to end. Every time you think you’re done, you realize you’re not. There’s “one more thing” you or your client wants to add. Somehow, you get exhausted and your work suffers. Sometimes you simply burn out and move on to something else. Why does this happen? Why do we consistently underestimate how much extra work it is to do “one more thing?”

read more

Sindre Sorhus blog.sindresorhus.com

Small focused modules

This was from an AMA, but Sindre turned it into a blog post since his response was so popular. Also, his answer applies particularly to Node.js. Sindre writes on his blog: Make small focused modules for reusability and to make it possible to build larger more advanced things that are easier to reason about. And, also… It doesn’t matter if the module is one line or hundreds. It’s all about containing complexity. Think of node modules as Lego blocks. You don’t necessarily care about the details of how it’s made. All you need to know is how to use the Lego blocks to build your Lego castle. By making small focused modules you can easily build large complex systems without having to know every single detail of how everything works.

read more

Opensource.com Icon Opensource.com

5 tips for choosing the right open source database

Choosing the right open source database is an important decision. Start by asking the right questions. All too often, people put the cart before the horse, making decisions before really understanding their needs. Solid tips by Barrett Chambers. Here’s another one courtesy of yours truly: Start your database selection journey by asking yourself, “Why not use PostgreSQL?” 😉

read more

 Itamar Turner-Trauring codewithoutrules.com

The next career step for Senior Software Engineers (that isn’t management)

This is a must-read for any software engineer wondering how they can move up the ladder without falling pray to the Peter Principle. Career progress for programmers doesn’t require giving up coding to become a manager. You can get more autonomy—and stronger negotiation leverage—by going from implementer, to problem solver, to problem finder.

read more

kate Matsudaira ACM

How to get things done when you don't feel like it

Kate Matsudaira provides 5 excellent strategies for pushing through: Even if you love your job, you don’t always feel like doing it every day. There are so many factors that influence your ability to show up to work with enthusiasm and then work hard all day long. From gamification to calendaring, Kate has a lot of good advice in this piece. I even learned a new word, “precrastination”, which I’ve been doing a lot of without even knowing it! 💪

read more

Dave Rupert daverupert.com

If statements should cost $10,000 each

Yup, it’s true…“estimating project costs is hard.” I thoroughly enjoyed the tongue in cheek logic shared by Dave Rupert in this post. …let’s say your app has a logged-in or logged-out state, well, that’s at least 2 if-statements. Starting price: $20,000. Never before has it been this easy to price and scope out complex stateful apps! The cost of complexity in software is real and this is a very practical post to share with would be customers of your software team. This applies to freelancers, consultants, and even teams inside larger orgs. We all have to account for our time, and that means accounting for the money being spent along the way.

read more

Brad Armstrong Medium

How to fail as a new engineering manager

Brad Armstrong lays it all out there about how to transition from an engineer to a manager: There are decades of books and thousands of blogs dedicated to trying to answer these questions, so I‘m not here to pretend that I’ve got the secret to success. But I do know a few ways that I’m pretty sure can guarantee you’ll fail. He takes you through 8 easy steps to failure. I’ll disappoint you now and spoil that step 1 is to keep coding 😱

read more

Yegor Bugayenko yegor256.com

Code must be clean. And clear.

Yegor applies a kitchen metaphor to code: The kitchen is clean when there is no dirt in the oven. But if its electric panel speaks French, I can’t use the kitchen. Even if it’s perfectly clean. It’s not clear how to use it—that’s why it’s useless. Sounds good to me, but how do you know if your code is actually clean and clear? He provides a heuristic: If a stranger can modify your code and fix a bug in less than an hour, it is maintainable. The entire post is well worth a read.

read more

0:00 / 0:00