> This way of writing software is a double-edged sword of course. It works a lot better for a small team of good, trusted programmers than it would for a big company of mediocre ones, where bad ideas are caught by committees instead of the people that had them.

http://www.paulgraham.com/road.html

High quality products were made for many years with no analytics, just by thoughtful design, using the product yourself, and gathering some feedback from users manually. Even without statistically representative data from some large target population, you can use your brain to figure out what goes wrong and how to make a good product.

And I think lots of products today are quite annoying because of bad decisions based on flawed analytics data. It's hard work to run a good experiment and avoid confounding correlations and plain bugs that throw off the results, and practically nobody today does the hard work. They just run the analytics, get some flawed buggy numbers, interpret them without sufficient care and thoughtfulness, and push through bad design changes. We're data-driven! We're just not looking at the road.

For me personally, two things that determine if somebody is in a position to give me advice are:

1)Are they enjoying a level of success that I would like to achieve? 2)Is the environment in which they achieved success comparable to my own?

The funny thing about "big data" in my experience, is just how small it actually becomes when you start using the right tools. And yet so much energy goes into just getting the wrong tools to do more...

I don't just do this with APLish languages; I do this with C (and lisp, and PHP, and others...)

I've only ever written short programs correctly: If they can fit on a page, I can just look and see whatever bug I might be experiencing.

If someone wants to change my software, it's because they want it to do something that I don't want it to do. They will find value in the fact it is short: That there isn't very much to read. Admittedly, a programmer unexperienced in this method may have some anxieties about it, but given how valuable correctness is, I'd prefer to cause a bit of anxiety in beginners than make programs that need beginners to fix them.

By programming them this way (avoiding programming in human frailties for the purpose of better "fitting in"), I think we can more quickly expose and correct certain areas where us bags of mostly salt water act suboptimally.

I think it was Tom DeMarco who popularized this slogan (or a popular variant of it), but he has abandoned it in later years, even going on to give counterexamples. See http://www2.computer.org/cms/Computer.org/ComputingNow/homep... .

defaults -currentHost write -globalDomain AppleFontSmoothing -int 3

defaults write -g CGFontRenderingFontSmoothingDisabled -bool false

There do exist components suitable for most environments, like Postgres, but usually at the cost of 10x complexity over what'd be needed for the pure functionality. That engineering is worth it for things like databases that get used everywhere, but not for any custom component.

By contrast, working from the comfort of my home is pure bliss. I have my standing desk and large monitor. I have natural sunlight filtering in through the window. I see some trees and hear the sounds of my quiet residential street. The rhythmic cadence of my mechanical keyboard soothes me and quietes my nerves. I’m focused and ready to take on a challenge of any size or complexity.

Meetings while WFH are not a major distraction. The other participants are cleanly separated from my world. I have a high-quality headset and microphone, which takes away the stress of being misunderstood. I can easily show my screen, or say nothing at all while tuning out a meeting that isn’t helping me get my job done.

I for one am waiting with bated breath for the world to catch up with the idea that some types of work are best done from home. Offices are the true black holes into which human productivity disappears.

I’m working on a SaaS service that does one thing really well, and I think it’s pretty close to being done. The code is very solid, and I rarely see any bugs or error reports (thanks to React, Immutable.js, and Flow.) The infrastructure is autoscaling and requires very little maintenance (thanks to convox.)

There’s always more features and integrations I could add, but I’m getting enough customers without them. It will require some ongoing work (e.g. updates for security vulnerabilities), but I’m not too interesting in trying to turn my table into a house. I'd rather follow the Unix philosophy and build a lot of very nice tables.

The amount of micro-management that goes into most programmers day to day work makes it extremely hard to be innovative, because you essentially have to justify what you're working on daily -- and any creative person knows that not every idea pans out. You need managerial support to occasionally make mistakes.

There have been a lot of times in other jobs where we'd have a slack in our schedule and I used the down time to make a change that was really necessary and took a minimal amount of time, mentioned it in a standup meeting, and got blasted for not working on our "commitments" for the "sprint" (even when I had nothing to do).

Companies always talk about wanting ideas from workers and how important innovation is, but they're not willing to extend the trust to their people to create an environment where that can happen. People naturally become disengaged when they're not trusted or valued.

The worst part is that it's not just management creating this mentality, it's the other programmers. I've noticed that younger more inexperienced programmers tend to crave the structure of agile, whereas the older more experienced programmers chafe at it. I think if programming had more of a culture of apprenticeship and mentorship, and a deeper appreciation that this is hard and it takes a long time to get good at it, our industry would be a lot healthier.

On the other hand, I've seen the other sides of this in monorepos:

1. It's too easy to depend on code, so there is dependency bloat when something simpler would work just as well.

2. It's relatively hard to depend on things not in the repo, reinforcing not-invented-here culture.

These days the throw away and rewrite/refactor crowd is in such power that if you don't spend 1/2 your time tracking the commits your likely to find that your dependencies are entirely incompatible with whatever you have built on them and you have no idea how to fix that short of reading the last 6 months of mailing-list (whatever) postings just to change the "runlevel" or get your service to start...

While there, I observed a lot of projects where I was literally working with a room full of world-class people - folks who had given TED talks, folks who had started major open-source projects, folks who had written the "Bible" of their particular subfield of computing - and the final design we came up with was worse than what any one person in the room, working on their own, could've come up with. Good designs tend to be both controversial and coherent: they take a position, not everyone agrees with the position, but they do it anyway because self-consistency has its own benefits that are often intangible but highly valued by users. When you design by compromise, you end up sanding off all the most innovative (= hard to communicate) parts of the design, and end up with only the bare minimum that everyone can agree on.

It's interesting that when you put a bunch of average people in a group, have them independently make a prediction, and then average the predictions, you end up with a result more accurate than any one participant's prediction. When you put a bunch of really smart people in a group, have them cooperate to make a design, and look at the design, you end up with a design that's worse than any one expert's original design.

I'm glad to work with other people, but it feels like the past ten years or so have strains of collectivism trying to crowd out the artisanal aspect because social or whatever. I'm sure part of it is the enormous incidental complexity brought on by the web.

"You can use Lisp if you want to."

"...I'll have the POC on your desk by next week."

Hire a bunch of smart people, give them advance funding for 5 years without strings attached, tell them to build the future without specifying what that means.

From a personal view I have plenty of ideas for things never built before, but I lack the time and energy to do it after hours and I can almost never fit it into the scope of my professional work. Sometimes this makes me sad.

At that point, you're not really talking about being an effective engineer, though. You're only talking about being an effective engineer in a large organisation working on a large project.

I know plenty of people in the freelancing and startup world who can build and maintain very significant systems single-handedly. Take someone with the skill and experience to do that, give them a free hand in choosing whatever tools and processes work for them to get a good job done, and remove the overheads of micromanaging this and co-ordinating that. It's not unusual for that person to outperform an entire team working for a competitor under more traditional constraints, or for a small number of such people who can keep the overheads down to outperform a more traditionally organised but mediocre team an order of magnitude larger. Of course these people also need good soft skills, but those are not why they are so productive.

This can cause a fair amount of friction as simplicity isn’t easy and newbs cannot differentiate those terms. Simplicity is the fewest instructions to perform a task, which often means fewer conventions and rituals in the code.

Some of the worst APIs I've seen have been ones designed by a backend developer based upon some vague specifications handed down by a non-technical PO. They were often designed with half of the stuff that was necessary missing, lots of stuff that wasn't necessary and some stuff which made no sense before being thrown over a wall.

The better APIs were 'designed' by the developer who would write the code that would consume them. Even if that just meant an email or a scrap of paper with a few example URLs and snippets of JSON.

There isn't any rational reason for knowledge workers to go to an office every day. Socializing and building a cult around a company might be the only reasons. But IDK if these are enough to justify an office.

There must be another solution we aren't aware of yet.

These people tend to create bureaucratic nightmare, an environment which demotivate creative people and promote mediocre people, an environment where you get rewarded to look busy instead of actually get things done.

Please, do not point me at agile manifesto.

To me agile looks like totalitarian sect which constantly preaches flexibility and freedom while swiftly punishing anybody who ever dare to deviate from strict daily rituals and mantras.

Dry definitions in agile manifesto means nothing in real life. What's actually important is a context which created by people who adopted it.

Agile/scrum is biggest cargo cult I've ever seen in my life.

But the end result was a crappy car. A lot of features were implemented in a subpar way. Nothing really fit and the car just didn't "feel" right.

With strict agile structures I feel the same happening. You check off stuff and on the surface you are doing everything right in a methodical way. But there is no mechanism to check if the overall result feels right and has cohesion.

Well, we could make it socially important to make remote work possible. The geographic concentration of tech thought and culture has been at least partly intentional.

Early internet culture seemed eager to do exactly the opposite. The inefficiencies of colocation were problems ripe for innovation.

If tech workers could live in small towns more easily, they'll have middle-class-squeeze conversations with friends and family, not just overhear other people having these conversations at local shops when they visit.

And all it takes is two chatty hires to ruin it (as a chatty person, I'm fine unless someone encourages me). If they kept a lot of private meeting rooms when they changed the floor plan, you have a good chance of convincing the chatty people to fuck off to a room if they want to talk, but most places don't do that. They use open floor plans to reduce costs, and then there are shortages of meeting space, kitchens, ventilation, and bathrooms.

The sales pitch of sitting in a group is that you can ask people questions and get an answer, but it's based on bad information about recovery periods after task switching. And as a lead I've been crippled by the inability to get candid answers from junior and midlevel engineers, and being unable to negotiate agreements with senior engineers by hashing out our disagreements in private where I can steer the conversation toward addressing their personal concerns instead of general ones. We should be concentrating on finding a compromise or promising more functionality so they're happy, so that it's two or three advocating for an idea when it's time to discuss it as a team. Instead it just gets shit on while I'm stream-of-consciousing it in the middle of a bunch of myopic people, leading to more confirmation bias and reaffirmation of the status quo.

[Edit] And good luck healing a rift between QA and dev if the QA folk have to wander into the lion's den to talk about an issue. I have only been a lead once in an open office plan (working on #2), because half of my skill is in knowing more about what's going on by liaising across functional or personality boundaries. Half of the rest is in fixing unidentified pain points, which often requires hearing from people who don't like to be a bother. Open plans don't encourage candor, they crush it like a bug.

Steve Job's line, as reported by Jonny Ive IIRC, about ideas being fragile and needing space to grow really hit home when I figured out I'm doomed to be in open offices until the pendulum swings back.