Practices Icon

Practices

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

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

JavaScript github.com

You probably don't need Moment.js

When you pull in a library dependency, it is rare that you need all of the functionality it offers. This isn’t usually a problem for backends, because that code never leaves the server. However, In frontend-land your users pay the price for all that unused functionality every time they hit your website with a cold cache. Moment.js is an excellent date/time library. It is packed with functionality, and you probably don’t need everything it has to offer. Instead, check out date-fns, which offers small, highly targeted functions you can probably get by with. There’s even an ESLint plugin that will help you identify places in your codebase where you don’t really need Moment.js!

read more...

Lorenzo Pasqualis coderhood.com

15 ways to achieve flow

What is flow? …a state of mental flow. Programmers live for it and work at their peak potential when they are in it. Also known as “the zone,” Flow is the mental state of operation in which a programmer is immersed in a feeling of energized focus, complete involvement, and enjoyment in the process of coding. Here’s a challenge — read this and apply just one idea to your work this week and report back in Slack how your work was impacted, positive or negative.

read more...

Practices programmingisterrible.com

Repeat yourself, do more than one thing, and rewrite everything

This contrarian post comes by way of the aptly named programmingisterrible.com. It’s a bit ranty, but I rather enjoy the author’s tone: If you ask a programmer for advice—a terrible idea—they might tell you something like the following: Don’t repeat yourself. Programs should do one thing and one thing well. Never rewrite your code from scratch, ever! He’ll take you step-by-step through why he thinks these generally accepted principles are often mistakes.

read more...

Eric Clemmons Medium

Work on features, not repositories

In response to a recent Twitter poll from Kent C. Dodds, Eric Clemmons shared concerns about how organizational boundaries are impacting where development happens. Kent tweeted… Hey folks who have a decoupled client-server application (no server rendering, server is just an API server). Where is your client code and server code located? (#) Together in one repo? In separate repos? Eric writes in his response on Medium: Software is like Jello: poke it in one place, and another place jiggles. In my experience, a repository should house all of the code necessary to make developing & shipping features relatively frictionless. This isn’t an exact 1:1, but this was a big part of the reason why Segment transitioned back to a monorepo.

read more...

Yegor Bugayenko yegor256.com

Builders and manipulators

Yego Bugayenko: Here is a simple principle for naming methods in OOP, which I’m trying to follow in my code: it’s a verb if it manipulates, it’s a noun if it builds. That’s it. Nothing in between. Methods like saveFile() or getTitle() don’t fit and must be renamed and refactored. Moreover, methods that “manipulate” must always return void, for example print() or save(). Let me explain. Naming objects well has been a career-long struggle for me. I just might give this a try…

read more...

Martin Fowler martinfowler.com

The state of agile software in 2018

Martin Fowler reflects on the journey of agile software development… Our challenge at the moment isn’t making agile a thing that people want to do, it’s dealing with what I call faux-agile: agile that’s just the name, but none of the practices and values in place. Ron Jeffries often refers to it as “Dark Agile”, or specifically “Dark Scrum”. This is actually even worse than just pretending to do agile, it’s actively using the name “agile” against the basic principles of what we were trying to do, when we talked about doing this kind of work in the late 90s at Snowbird. The three main challenges we should focus on are: fighting the Agile Industrial Complex and its habit of imposing process upon teams, raising the importance of technical excellence, and organizing our teams around products (rather than projects).

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