michaelfeathers

de jure != de facto

In practice it was used far more for type.

I think that the most important thing to understanding about naming is how it interacts with scope. Class names tend to be longer because there is no outer scope (unless you have packages or namespaces). Likewise, single character names are fine in very localized contexts like this:

users.map {|u| "(" + u.first_name + ")" }

'u' would be a very bad variable name in a broader context. Here, we can easily see it's a user.

I don't think it would. Implementation of the language would be easier, though, and I suspect that knowing that memory is not reclaimable might act as a beneficial constraint on design.

This makes me wonder whether it would be worthwhile to design languages with no garbage collection or manual deallocation. Non-stack memory can be allocated but never freed, and memory exhaustion would be fatal.

We might be at the point where this is an acceptable simplification for very fine grained processes and services. Has anyone explored this model?

The great thing about exceptions is that they allow you to put arbitrary distance between the point of detection and the point of handling.

The problem with exceptions is that they allow you to put arbitrary distance between the point of detection and the point of handling.

There is a lot of data on this topic.

This is a good starting place: http://www.amazon.com/Garbage-Collection-Algorithms-Automati...

You don't "Learn to Code" so you can do it yourself. You do it to understand your business. Code will affect what your business can do, and when, more than you realize.

Bill, it's interesting to read your reply and see your worldview. It looks like you've had way worse experiences with employers than with governmental entities, and you see living with the former way worse than living with the latter. I know people who see the world in exactly the opposite way. They'll rail all day about how the government affects their lives and constrains their choices (and they have very concrete examples) yet they are happy working within constraints at work and see more opportunity there than they do in their governmental dealings.

Realistically, they have options in both spheres, but they only feel one oppressively and they tend to assume that everyone else does too. Where power is exercised at work they are okay with it - they recognize it as part of the system and don't feel like cogs.

I wish you the best in finding new glasses to see the world of work through, just as I wish the same for people I know who are fighting governmental oversteps. The key thing is - it's not all bad. There is badness out there but structure is not determinative. Look for happy people in any system. You'll find them. What we look for in life does affect what we see, and what we create. Best of luck to you.

> The first part makes sense to me, although I don't think I've ever personally seen it happen. What percentage of companies would you say operate in the fashion you describe?

Ever worked in a chain restaurant? Camaraderie among coworkers at a site under a manager (so hierarchy) and not as much peer connection across sites.

I'd argue that you are using a narrow definition of hierarchy that is centered on ideas about power rather than dynamics in emergent systems. The arterial structure of a leaf is hierarchical. So are airport connection patterns. Whenever you have preferential attachment or costs associated with material or information transfer there's a force toward hierarchy, designed or not. Systemic effect. No primates needed.

The interesting bit to me is that if we considered something non-sentient, like a network router that controls flow over a set of nodes, it would be easy to anthropomorphize it purely based on its behavior and see it as exerting dominance when it makes its routing decisions if they don't align with what we want at that moment. Although there can be abusive hierarchy, there's something deep to be considered in that scenario. We might be inclined to see all hierarchy as bad because that sort of conflict of interest can happen, willed or not. That's why, where there are power relationships in employment or even representative democracy, systemic integrity and human values depend upon gaining and maintaining consent.

At scale many organizations create substructure that contain strong peer culture and human-centered process, so it isn't lost, it's localized.

I think that the big challenge is to recognize that hierarchical structure isn't good or bad, it's something that most natural systems do in response to scaling. If we understand it as a design parameter we can make it humane.

It's funny we make the presumption that the natural way is the best way.

Here's a Ruby version in 16 lines of code: https://gist.github.com/michaelfeathers/2cf9e1599e06d0563f2e

We put a variation of the script to music also. Seriously. It's on iTunes and Bandcamp:

https://itunes.apple.com/us/album/snippets-programming-episo...

https://fowlerandfeathers.bandcamp.com/releases

Intuition is great but we often forget that we can use churn stats too.

find . -name "*.rb" |xargs -n1 -I file sh -c 'echo `git log --oneline file | wc -l`: file'|sort -nr

Applying a time period window is good too as some parts of code churn for a while and them reach stability.

I wonder whether there is a "soft" Dunbar number for collaboration networks?

If this goes through Warrant Canaries will become much more popular.

nor·mal - adjective 1. conforming to a standard; usual, typical, or expected. "it's quite normal for puppies to bolt their food"

All the things that he writes about are normal - they happen. People (myself included) with an engineering background are surprised when things don't "make sense" or people don't do things the "right way." The trick is to get to the point where these things are not surprising, where you see them as part of the systems you are trying to understand and consequences of forces that aren't mysterious, they are just part of human social dynamics. From that vantage point you can get a better sense of what you can change to influence outcomes and whether you can or can't in a particular context.

This. It's kind of sad to see a new term invented for what Ward called 'Technical Debt.'

I think that we arrived here specifically because we don't have a term for the effect of careless code change. 'Technical Debt' ended up being appropriated as a term for it.

The idea of being a full stack developer has been around for a while. It's good but it only covers one dimension - the vertical.

The real win is to go horizontal. The same people do market analysis, design coding, testing, and prod support. We can't all be experts, but most of us can develop enough skill to do this. The elimination of hand-offs removes delay and miscommunication.

I've always regarded that paper as the 'Godel's Incompleteness Theorem' of Security.

I'm not saying that the security field had a 'Hilbert's Program' before then, but it certainly couldn't have one afterward.

Close, but not quite there. You should leap over tall buildings to make sure that you never have to set y to null.

In my code, I'm only dealing with null if a API gives me one. At that point, I take some sort of action to make absolutely sure I'm not passing it along to anyone else. This means using exceptions, the null object pattern, or Optional without a need to dereference. The goal is to prevent a proliferation of references that could be null and therefore have to be checked.

Here's a functioning sociopath with a conscience but it's not feeling based. It seems very similar:

https://www.psychologytoday.com/articles/201305/confessions-...

Isn't this textbook sociopathy?

Sometimes I feel that software engineering is really three separate disciplines: ergonomics, type theory, and sociology.

I think the most important takeaway from this article might get lost in the other points it makes: you are better off when you have fewer features and have fewer features that interact with each other.

20KSLOC programs just don't appear out of thin air. They start as small programs that, if you apply good programming practices, can scale beyond 2KSLOC. And if you apply good program design practices can scale up to 20KSLOC. But all along the way you'd better be thinking about whether you really need a particular feature and how coupled it will be with the other ones. That should happen in every program. The problem is that we are not used to challenging the features that are selected for our systems and recognizing their price as the system grows.

> Most luggage isn't really secure in the first place

Nothing is secure, really. I'm continually amazed that people want to see security as a binary thing.

I don't like seeing the language of addiction and recovery expanded to new areas like this. It's a way of putting moral frame on behavior that can be healthy and enriching.

I first felt this way when I saw "addiction" applied as a label to kids who prefered playing video games to going outside. My response was "did they call it addiction before video games when kids played with blocks and action figures indoors?" They didn't. It's easy for people to reach for the term "addiction" when they want to pathologize behavior they don't like.

Fact is, the dopamine cycle is a natural part of life. The problem isn't whether something is addictive or not, it's whether the side effects of that pleasure cycle are harmful. I've had periods in my life where I've spent weeks and months at a time "heads down" in programming. It was always as controllable as it was pleasurable.

I really wanted this to be about a typewriter that goes to the top and bottom of a piece of paper on 'gg' and 'G'.

> It says there was no evidence of drugs but then goes on to say that the toxicology report would take 2-3 months.

Hard to believe it takes so long in the 21st century. Is that bureaucracy or science?

Some website a few years ago said that Lynch's Dune is great if you cut out all of the speaking parts. I'd like to see an edit like that.