nicolashery + practices   103

Lean Testing or Why Unit Tests are Worse than You Think
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.
practices  testing 
4 weeks ago by nicolashery
Manual Work is a Bug - ACM Queue
By constantly documenting and creating code-snippet artifacts, you accelerate future work. That one-shot task that could never happen again, does happen again, and next time it moves faster. Even tasks that aren't worth automating can be improved by documenting them, as documentation is automation.
documentation  practices 
6 weeks ago by nicolashery
7 mistakes that cause fragile code
My goal in this booklet is to show you some counterintuitive ideas about what
makes bad code, and to share some of the few resources that exist for helping
you reach a higher level. Hopefully, some will already be familiar to you. But if
I can show you one thing that’s surprising and shifts the way you think about
programming, then I’ve done my job.
practices  pdf 
12 weeks ago by nicolashery
Write code that's easy to delete, and easy to... — programming is terrible
Debuggable code is code that doesn’t outsmart you. Some code is a little to harder to debug than others: code with hidden behaviour, poor error handling, ambiguity, too little or too much structure, or code that’s in the middle of being changed. On a large enough project, you’ll eventually bump into code that you don’t understand.
programming  practices 
may 2018 by nicolashery
the Origins of Opera and the Future of Programming – Jessica Kerr – Medium
At the end of this post is an audacious idea about the present and future of software development. In the middle are points about mental models: how important and how difficult they are. But first, a story of the origins of Opera.
practices  management 
april 2018 by nicolashery
Waterfall Deconstructed | Silicon Valley Product Group
This is why I push teams, whatever their preferred process or techniques, to ensure they are focused on these three big areas: tackling the risks up front, defining products collaboratively, and focusing on results.
product  practices  agile 
february 2018 by nicolashery
Making Bugs Impossible: Illustrating the Embedded Design Principle | Path-Sensitive
The Embedded Design principle, which I briefly introduced in a previous post, states that you should always code in a way that makes the design apparent. It’s like pixie dust in its ability to make code more readable, loosely coupled, and impervious to bugs.
practices  programming 
february 2018 by nicolashery
How we built a distributed, self-funded, family-friendly, profitable startup
This blog post serves two purposes. First, the company is starting to grow quickly, so we’ve created this blog post as a guide for job candidates and new hires. Second, we’re not the first people to build a company, so in the interest of learning, forcing ourselves to improve, and being transparent, we’re publishing this as a public blog post.
practices  management 
february 2018 by nicolashery
DRY revisited - Enterprise Craftsmanship
The DRY principle is about domain knowledge.
Don’t confuse adhering to DRY with getting rid of code repetition.
There are cases where code duplication is perfectly fine.
practices  programming  ddd 
february 2018 by nicolashery
In Pursuit of Production Minimalism — Brandur Leach
Most of us can benefit from architecture that’s a little simpler, a little more conservative, and a little more directed. Only by concertedly building a minimal stack that’s stable and nearly perfectly operable can we maximize our ability to push forward with new products and ideas.
practices  opinion 
january 2018 by nicolashery
12 Things to Help Large Organizations Do Angular Right
The four (4) main areas that can have the biggest impact on your organization are: source code management, dependency management, promoting best practices, and automation.
angular  practices 
january 2018 by nicolashery
Making a mess less | f3yourmind
I caught myself saying this the other day and it made me think about how I deal with a mess.  For me, a messy problem is one that has more than 2 inputs and outputs.  My brain struggles to resolve that.  I just can’t do NxM matrices in my head.
practices  math 
december 2017 by nicolashery
No Silver Bullet – essence and accident in software engineering | the morning paper
Today’s choice must be one of the best-known essays on software engineering of all time. Everyone knows the “no silver bullet” line, but how long is it since you last acquainted yourself with the details of the argument?
programming  practices  paper 
december 2017 by nicolashery
Modern Software Over-Engineering Mistakes – RDX – Medium
Many articles say Dont over-engineer but don’t say why or how. Here are 10 clear examples.
programming  practices 
december 2017 by nicolashery
Faster, Better, Cheaper—The art of making software
And yet, so many software projects don’t go well. And with every new project, there seems to be more and more pressure to go faster. So, if we’re in the business of making software, what do we do? How do we go faster without compromising quality?
practices  programming 
december 2017 by nicolashery
(54) One Bite At A Time: Partitioning Complexity
A recent programming project of my own reminded me that just because I can’t handle lots of complexity at once, it doesn’t mean I can’t program. I can program, but because of my weakness I use a style that partitions complexity instead of consuming it whole. Here are the elements of that style.
practices  programming 
november 2017 by nicolashery
McSoftware – Hacker Noon
What if they don’t like being treated like a cog in a machine any more than anyone else? What if all they want is a little bit of freedom to put a ketchup smile-y overtop the cheese? Could it be that it’s a bad idea to reduce engineers to robots who ask: “Would you like apps with that?”
management  practices  opinion 
october 2017 by nicolashery
My 20-Year Experience of Software Development Methodologies | zwischenzugs
Recently I read Sapiens: A Brief History of Humankind by Yuval Harari. The basic thesis of the book is that humans require ‘collective fictions’ so that we can collaborate in larger numbers than the 150 or so our brains are big enough to cope with by default. Collective fictions are things that don’t describe solid objects in the real world we can see and touch.
agile  practices 
october 2017 by nicolashery
"Incident insights from NASA, NTSB, and the CDC" by Emil Stolarsky - YouTube
All complex systems eventually fail. With that inevitability, understanding recovery is paramount. Beyond the investment to keep a system running, we must know how to effectively recover upon failure, and ensure we don't encounter the same failure twice. The stakes are high: in a connected future, one with self-driving cars and fully-automated economies, outages won't only damage customer trust and the bottom line, but could cost lives.
practices  formalmethods  video 
october 2017 by nicolashery
Uncle Bob and Silver Bullets • Hillel Wayne
But unit tests are not enough. Type systems are not enough. Contracts are not enough, formal specs are not enough, code review isn’t enough, nothing is enough. We have to use everything we have to even hope of writing correct code, because there’s only one way a program is right and infinite ways a program can be wrong
practices  formalmethods  tlaplus 
october 2017 by nicolashery
How Code Becomes Legacy – Bruno Filippone – Medium
Having code you wrote more than a decade ago still running in production is a great achievement and definitely something to be proud of. If you currently have projects that no one really knows how they work or no one really wants to work on take a step back and try to figure out what went wrong.
practices  techdebt 
october 2017 by nicolashery
What have you learned after working at Facebook for almost two years? Have you grown as a developer and what are some of the key takeaways? - Hashnode
What have you learned after working at Facebook for almost two years? Have you grown as a developer and what are some of the key takeaways?
programming  practices 
september 2017 by nicolashery
How to write maintainable code - Peter Hilton
Modern languages’ biggest problem isn’t having enough cool features, it’s unmaintainable code. The core of maintainable code is clean code with good tests, but that by itself is not enough. This talk introduces a range of techniques for writing and improving code for maintainability, including how to get better at naming, explaining code with tests, the few code comments you actually need, README-driven development and how to write Minimum Viable Documentation.
practices  slides 
september 2017 by nicolashery
Write Less Code · CodeAhoy
If you love writing code– really, truly love to write code– you’ll love it enough to write as little of it as possible.
practices 
august 2017 by nicolashery
YAGNI, Cargo Cult and Overengineering - the Planes Won't Land Just Because You Built a Runway in Your Backyard · CodeAhoy
You may have great reasons to use MapReduce or SOA. What matters is how you arrive at your decision. Whether by careful, sane thought or by jumping on the bandwagon and cargo-cult’ing.

As my professor said: “Pick the right tool for the job.” I’ll also add: don’t build Formula One cars when you need a Corolla.
practices  microservices 
august 2017 by nicolashery
Software Engineering ≠ Computer Science | Dr Dobb's
In the same way, classical computer science is helpful to software engineering, but will never be the whole story. Good software engineering also includes creativity, vision, multi-disciplinary thinking, and humanity. This observation frees software engineering researchers to spend time on what does succeed -- building up a body of collected wisdom for future practitioners. We should not try to make software engineering into an extension of mathematically-based computer science.
programming  practices 
august 2017 by nicolashery
Frameworks: Necessary for large-scale software (evanjones.ca)
However, since joining Twitter three months ago, I've decided that good frameworks are necessary for large-scale software engineering. When hundreds of engineers work on a single project, there needs to be common high-level building blocks.
programming  practices 
august 2017 by nicolashery
The Hard Thing About Software Development | Jesse Watson | Pulse | LinkedIn
I call it the "One Skull Rule": "The most valuable asset in the software industry is the synthesis of programming skill and deep context in the business problem domain, in one skull." (Software Development Manager at Amazon Fulfillment Technologies)
software  practices  opinion 
july 2017 by nicolashery
How to choose technology - Sebastian Daschner
We as developers of course tend to new hot technologies, the latest hypes, and applying them immediately in our daily work. However, such premature implementation will probably cause some bad surprises later.
practices  java 
july 2017 by nicolashery
Why I Hate Slack and You Should Too - bitquabit
Yeah, that’s right: there’s finally something I feel so negatively about that I’m unsatisfied hating it all by myself; I want you to hate it, too. So let’s talk about why Slack is destroying your life, piece by piece, and why you should get rid of it immediately before its trail of destruction widens any further
practices  opinion 
july 2017 by nicolashery
How Software Gets Bloated: From Telephony to Bitcoin
So, how does software get bloated? Who is behind it? What process is at fault?
software  practices 
july 2017 by nicolashery
Levels of Techie Enlightenment
I have come to realize that there is a common path people follow when mastering a technology. There are three distinct stages, or levels of enlightenment, that individuals proceed through.
practices 
july 2017 by nicolashery
AgileBits Blog | Curing Our Slack Addiction
Slowly but surely this addiction has been killing my sanity and sapping our productivity as we simply used Slack for too many things. We decided it was time to try a new approach for communication at AgileBits.
practices 
june 2017 by nicolashery
Why we’re betting against real-time team messaging – Ten Timezones
Real-time chat apps are taking the business world by storm. But does faster communication really mean better communication?
practices 
june 2017 by nicolashery
Code rant: The Configuration Complexity Clock
You already have a general purpose programming language, before you go down the route of building a business rules engine or a DSL, or even if your configuration passes a certain level of complexity, consider that with a slicker build-test-deploy cycle, it might be far simpler just to hard code it.
programming  practices 
may 2017 by nicolashery
Systems in production – Jesper L. Andersen – Medium
The maintenance period of a project is often measured in years, whereas the time to build the project is measured in months. Thus, the maintenance period by far dwarf the initial construction period.
devops  practices 
may 2017 by nicolashery
Hype Driven Development – DaftCode Blog
Someone reads a blog post, it’s trending on Twitter and we just came back from a conference where there was a great talk about it. Soon after, the team starts using this new shiny technology (or software architecture design paradigm), but instead of going faster (as promised) and building a better product they get into trouble.
programming  practices  opinion 
may 2017 by nicolashery
Managing Technical Debt – Hacker Noon
Keep points of flexibility in the right places
Design your software as you would design a building. You have slow moving parts and fast moving parts. Some components, like furniture or wall paint, are loosely coupled to the building. It’s far hard to change the angles at which the walls meet. You have to pick your battles.
techdebt  practices 
may 2017 by nicolashery
Structure and Interpretation of Computer Programmers : Working Effectively with Legacy Code
I gave a talk to my team at ARM today on Working Effectively with Legacy Code by Michael Feathers. Here are some notes I made in preparation, which are somewhat related to the talk I gave.
practices  techdebt 
may 2017 by nicolashery
Stop spending engineering effort solving problems you don’t have
If you are writing a web app — a great web app, a fantastic web app, THE BEST EVER WEB APP — you do not need a container orchestrator. You need a PaaS. You do not need 5 different ways to deal with rolling out new versions of your app. You do NOT need to be able to configure and tweak your database. Do not manage your own database!
programming  practices 
may 2017 by nicolashery
Abstractivate: Reuse
Here's the thing: sharing code is dangerous. Do it sparingly.
programming  practices 
may 2017 by nicolashery
The alarming state of secure coding neglect - O'Reilly Media
That’s one of the key findings in a survey of 430 professionals—mostly everyday programmers—carried out during December 2016 and January 2017 by O'Reilly Media along with the Software Improvement Group (SIG), an international consultancy firm specializing in software quality measurement and advice.
security  practices 
may 2017 by nicolashery
The Architects Below – The Composition
Automation adds value. Consistency. Repeatability. Documentation (the only real documentation is code). No context switching. Fewer errors — the less frequently we do something, the higher the error rate, so the higher the value of automation. We don’t just remove work! We remove fear.
programming  practices 
april 2017 by nicolashery
Education of a Programmer – Hacker Noon
When I left Microsoft in October 2016 after almost 21 years there and almost 35 years in the industry, I took some time to reflect on what I had learned over all those years. This is a lightly edited version of that post. Pardon the length!
programming  career  practices 
april 2017 by nicolashery
I've been a Web Developer for 17 Years, and this is what I learned - Daniel Khan | @RisingStack
If you read any book, read this book - it's the Pragmatic Programmer. Many of the rules you find inside are kind of inherent in all the philosophy I was talking about.
programming  practices 
march 2017 by nicolashery
Almost 15 years of using Design By Contract - Philippe Bourgau's blog
I first read about Design By Contract in 2002, in Object Oriented Software Construction 2. As soon as I read it, I was convinced, today, I still believe it’s a great and fundamental technique. That’s why, I almost never write a contract ! Let me explain.
programming  practices 
march 2017 by nicolashery
18F: Digital service delivery | The Dark Standup
Our Director of Operations told the team “I only want you to work eight hours a day, five days a week, for the next two weeks, and I want to know how that changes the way you work. No peeking at phones or Slack or e-mail in off hours.”
practices  agile 
march 2017 by nicolashery
Lessons Learned from Not Documenting
In this post I’m discussing lessons I’ve learned about documentation where I really should have been doing something, but haven’t been. Every single lesson is, at the time of writing, something I am about to implement, or have implemented within the last week. Every single one is something I see immense value in. Every single section has concrete implementation steps at the bottom.
practices  documentation 
march 2017 by nicolashery
Paul Chiusano: The design failures of view-first
This post advocates a design philosophy I’m calling view-inspired, model-driven. We’ll look at a domain, task-tracking and project management, and examine the failure of an alternate philosophy, ‘view-first’, using Trello as the case study
practices  haskell 
march 2017 by nicolashery
Moving Airbnb Search to React – Airbnb Engineering & Data Science – Medium
In early 2016, we decided to start refactoring the search page into React.
web  practices 
march 2017 by nicolashery
ryanmcdermott/clean-code-javascript: Clean Code concepts adapted for JavaScript
Software engineering principles, from Robert C. Martin's book Clean Code, adapted for JavaScript. This is not a style guide. It's a guide to producing readable, reusable, and refactorable software in JavaScript.
javascript  practices 
january 2017 by nicolashery
Code Simplicity » How to Handle Code Complexity in a Software Company
So what can you do as a manager, if you have a complex codebase and want to resolve it? Well, the trick is to get the data from the individual contributors and then work with them to help them resolve the issues.
practices 
december 2016 by nicolashery
longflow-manifesto/README.md at master · Nax/longflow-manifesto
This is the key principle of the longflow methodology: everything has to be done with long-term goals in mind.
practices 
december 2016 by nicolashery
How terrible code gets written by perfectly sane people – Christian M. Mackeprang
When I found out I would be working on porting an old Python codebase to Node, I was slightly excited. These kinds of projects always give you more creative freedom than the ordinary code maintenance gig, and something about the challenge of rewriting other people’s code makes it fun as hell.
programming  practices 
december 2016 by nicolashery
The perils of shared code
In almost every project in which the organization went for a microservices architecture, individual teams and developers were expected to base their microservices on some core library.
microservices  practices 
december 2016 by nicolashery
Naming smells - Peter Hilton
Sometimes, when you’re reading code that looks nice and clean but which doesn’t quite make sense, the problem lies in the naming. Naming smells are code smells that come from bad names.
programming  practices 
december 2016 by nicolashery
Some things that might help you make better software | David R. MacIver
I’ve argued before that most software is broken because of economic reasons. Software which is broken because there is no incentive to ship good software is going to stay broken until we manage to change those incentives. Without that  there will be no budget for quality, and nothing you can do is going to fix it.
programming  practices 
december 2016 by nicolashery
Abstractivate: Areas of responsibility
See, I model our team's areas of responsibility as three circles. The yellow system is everything we're responsible for -- all the legacy systems and infrastructure have to belong to some team, and these are carved out for us.
practices 
december 2016 by nicolashery
Why you should use a single repository for all your company’s projects | David R. MacIver
In my post about things that might help you write better software, a couple points are controversial. Most of them I think are controversial for uninteresting reasons, but monorepos (putting all your code in one repository) are controversial for interesting reasons.
monorepo  practices 
december 2016 by nicolashery
Rewrite or Refactor? - DaedTech
After all, I can think of few topics in software development that draw as much debate as this one.  “We’ve got this app, and we want to know if we should refactor it or rewrite it.”
practices  programming 
december 2016 by nicolashery
An excerpt of the Elevence development repository
The code in the sibling directories provides an excerpt of the Elevence development repository and is intended to serve as a template for other companies that want to start using Haskell in production.
haskell  git  practices 
december 2016 by nicolashery
EnterpriseReady - Build SaaS Features Enterprises Love
Created for people who build SaaS products (founders, product managers and engineering team leads) to change the enterprise software narrative from "how to SELL to the enterprise" to "how to BUILD for the enterprise".
enterprise  practices 
november 2016 by nicolashery
Software (r)Evolution — Part 1: Predict Maintenance Problems in Large Codebases | Empear
Welcome to the first part in the Software (r)Evolution series! Software (r)Evolution is a series of articles that explore novel approaches to understanding and improving large-scale codebases. Along the way we’ll use modern data science to uncover both problematic code as well as the behavioral patterns of the developers that build your software. This combination lets you to identify the parts of your system that benefit the most from improvements, detect organizational issues and ensure that the suggested improvements give you a real return on your investment.
programming  practices 
november 2016 by nicolashery
To-Do Lists Are Not the Answer to Getting Things Done – Personal Growth – Medium
To help you say no you need some friction. The solution to the to-do list problem is actually pretty simple. You have to make one change: schedule it.
practices  lifestyle 
november 2016 by nicolashery
You Are Not Paid to Write Code – Brave New Geek
We should embrace the principles of systems theory and Taco Bell Programming. New systems or more code should be the last resort, not the first step. Further, we should embody what it really means to be an engineer rather than measuring raw output. You are not paid to write code.
practices  management 
november 2016 by nicolashery
Interview to Erik Dietrich on Static Analysis and a data driven approach to refactoring - Federico Tomassetti - Consultant Software Engineer
Erik Dietrich is a well known Software Architect with a long experience in consulting. His blog (DaedTech) is a source of thoughtful insights on software development. In particular I was very interested by his usage of static analysis and code metrics in his consulting work.
practices  staticanalysis 
november 2016 by nicolashery
JUXT Blog: Waste
I want our company to keep it honest and to avoid waste just like the client will want us to. This requires thinking like the developers who aren't consultants and who will be living with the solution for the long term.
programming  practices 
november 2016 by nicolashery
Just shut up and let your devs concentrate, advises Stack Overflow CEO Joel Spolsky - GeekWire
If you want to attract and keep developers, don’t emphasize ping-pong tables, lounges, fire pits and chocolate fountains. Give them private offices or let them work from home, because uninterrupted time to concentrate is the most important and scarcest commodity.
practices  management 
october 2016 by nicolashery
Semantic Meaning in Authoring Documentation — Surfing in Kansas
We might want to warn someone in our writing, but we don’t want to think about how to display this. Writing with Semantic Meaning gives us this power.
practices  documentation 
october 2016 by nicolashery
::..: glen.nu :.: ramblings :.: on code review :.::
Code review should probably always be your top priority, and you should figure out the best way to work it into your event loop.
Make your review requests a pleasure to read.
management  practices 
september 2016 by nicolashery
Abstractivate: Tradeoffs in Coordination Among Teams
In databases we choose between Consistency (the data is the same everywhere) and Availability (we can always get the data). As teams grow, we choose between Consensus (doing things for the same reasons in the same way) and Actually-getting-things-done.
Or, letting go of the CAP acronym: we balance Moving Together against Moving Forward.
practices  management 
september 2016 by nicolashery
Live asynchronously.
Last year I turned off all my notifications. I stopped booking meetings. I started living asynchronously.
practices  management 
september 2016 by nicolashery
What are some of your favorite newer best practices? | Lobsters
What are some of the new best practices/tooling (not specific products necessarily, but concepts that specific products implement) that you’ve used and enjoyed having in the past year or two? I understand this question is fairly broad.
practices  haskell 
september 2016 by nicolashery
Lessons Learned From Software Rewrites
Software rewrite is a quite painful process, no matter which strategy you choose to use.
practices  techdebt 
september 2016 by nicolashery
Arguments against JSON-driven development
I don't have to explain how popular JSON is. There are very few projects that don't need to work with JSON, even when they are not related to network programming. The ubiquity of JSON is causing some developers to rely on it a bit too much, however.
python  practices 
august 2016 by nicolashery
Brainstorming Is Dumb | Co.Design | business + design
But it turns out that brainstorming is actually a terrible technique—in fact, people generate fewer good ideas when they brainstorm together than when they work alone. Thankfully, there’s a better way: a technique called brainwriting (think brainstorming, but with a pen and paper and less chitchat).
practices  management 
august 2016 by nicolashery
The Human Cost of Tech Debt - Evangelism - Infragistics.com Blog
If you're not already familiar with the concept of technical debt, it's worth becoming familiar with it.  I say this not only because it is a common industry term, but because it is an important concept.
practices 
august 2016 by nicolashery
« earlier      
per page:    204080120160

Copy this bookmark:



description:


tags: