Hacker News Reader

matfilon I ruin developers’ lives with my code reviews and I'm sorry

When did code reviews become so ubiquitous?

Articles complaining about the reality of code reviews seem to be commonplace. But if they're not working out, why not just abandon them, maybe try something different?

matfilon Ask HN: Top three questions for a startup before accepting a job offer?

The big one for me: how strongly do you equate "programming" with "engineering", and to what extent do you value other approaches (in the spirit of [1])?

To what extent are ways of working circumscribed by tooling choices?

"What are you selling?" (and is it something I can believe in) is pretty important too.

[1] https://www.tedinski.com/2018/03/20/wizarding-vs-engineering...

matfilon Ask HN: What are the most fun areas of programming?

Getting a bit more meta, are you task-oriented, goal-oriented, people-oriented? What truly makes 40 hours a week more pleasant for you?

This question really resonated. Do you have any advice to someone who's pretty strongly down the "goal-oriented" end of this? Fundamentally, I enjoy the work, but do find a queue of 20 JIRA tickets (which I imagine to be the the "task-oriented" way) drastically less appetising than a few meaty problems to dig into.

matfilon Ask HN: What's your biggest pain point when hiring developers?

There are experienced people who aren't terribly interested in "big-N" companies. Think about what you can offer other than money.

Private offices and/or remote working? More influence over technology choice? A more individualistic style of working, where you're allowed to take a non-trivial problem and disappear on your own for a few weeks? Those would all be big draws for me. I'm sure there are other positive ways to differentiate your culture.

matfilon Ask HN: What would your ideal issue tracker look like?

Titles, optional brief descriptions, and an absolute minimum of other stuff. Not lots of structured fields. Definitely not custom states and flow-charts. If there's extensively discussion to be had, put that elsewhere. Ideally, e-mail.

I just want a TODO list to glance over occasionally, not a system that can turn into full-time job in its own right.

matfilon Ask HN: What would your ideal issue tracker look like?

I'd argue that "generating reports" is quite possibly an anti-feature in an issue tracker. It's a strong indication that whoever is building this thing is on the side of the managers, not the doers.

matfilon You Weren't Meant to Have a Boss (2008)

Likewise. His more programming-centric writing, in particular, is a breath of fresh air relative to the current "teams, tests, and tickets" dogma. Personal favourite: http://paulgraham.com/head.html

matfilon You Weren't Meant to Have a Boss (2008)

What if employees were offered a substantial degree of choice in which projects they're assigned to. At that point, risky projects would need to have commensurate rewards attached. Does this solve the problem?

Valve, for example, seems to take this sort of approach, and while it's not without criticism, it seems to work okay for some people.

matfilon You Weren't Meant to Have a Boss (2008)

I would be interested to work in a "10 groups of 10"-shaped company. I've never really encountered one, though, and I think it would be fairly unstable. Example failure mode: someone starts grumbling about "silos", and before you know it there's an effort afoot to standardise some or other technology or practice across the groups. At that point, one of the groups that's gone furthest in terms of formalising/making rules for that area almost always end up winning, and there's a gradual levelling up of process, and thus levelling down of autonomy.

matfilon Travels with Smalltalk (1995)

Yes.

The one strange thing is that it seems to have caught IBM somewhat off-guard.

matfilon Programmer as wizard, programmer as engineer (2018)

That may be true, but immediately makes me think of Rich Hickey's "constants matter".

matfilon Travels with Smalltalk (1995)

I'm certainly with you on The Cloud. I've been expecting a backlash for a while, but not much sign of it so far. A big monthly bill from $CLOUD_VENDOR_OF_CHOICE seems to have become this century's equivalent of "nobody gets fired for buying IBM".

Makes me think: a few years ago, there was some or other beer in the UK that was (heavily) advertised with the slogan "reassuringly expensive". The Cloud vendors (perhaps AWS in particular) seem to be going down that path a bit. Very interesting to juxtapose the reluctance to pay for software with an apparent eagerness to pay for Cloud services.

matfilon Travels with Smalltalk (1995)

Twenty years ago (crikey, that long?), I was a pretty vocal Open Source advocate. At the time, it seemed like the only way to avoid a Microsoft monoculture, and I'm still not sure that wasn't true. But now we're seeing monocultures of corporate-sponsored open source (Chrome/Blink's dominance seems particularly alarming in this sense), and managers who are more reluctant than ever to accept technical solutions which aren't "standard".

I'd love to know how to bring back a bit more diversity to everyday computing. Beyond using niche systems for hobby projects, leverage seems rather limited right now.

matfilon Programmer as wizard, programmer as engineer (2018)

Thanks, that's a pretty interesting take.

(Also a reminder that we're probably going to lose some interesting stuff when Google+ goes kaboom...)

matfilon Ask HN: How do you fix engineering culture?

Make sure you understand why this person left engineering. "Integrating him with his old team" could be good, but could also be throwing him right back into the middle of something he was actively trying to get away from.

matfilon Ask HN: How do you fix engineering culture?

Engineering was supposed to maintain the current software, but they (engineering) chose to deprecate it and make a new version from scratch. It is just taking way longer than expected, three years and just a fraction of the original functionality.

This seems like a key issue. It's time to evaluate progress on the re-write and work out what to do next, with all options on the table (including re-focussing on the old software, or even starting afresh with a "version 3").

Are there any people in the engineering group who have been doing non-trivial bits of work on the old software? It may be worth cultivating these people and taking their opinions seriously, even if it ends up putting other (perhaps more senior) noses out of joint within the engineering group.

matfilon Ask HN: How do you find roles as a solo developer?

Also curious about this, and in particular what the alternatives to shortish-term consulting could look like.

A model I've been wondering about is offering longish-term contracts to build/support/maintain some capability. Perhaps could be thought of as a kind of one-customer SAAS. Anyone tried a model like this?

matfilon Ask HN: How do you fix engineering culture?

I’ll second the Joel test. But like a lot of “modernisations”, I think the version you give has lost some of the spirit of the original. Less room for individuality, more tooling, rules, and processes. And losing “quiet working conditions”, in particular, is a big change.

I still find the original holds up pretty well in many environments.

matfilon Essential C (2003) [pdf]

I think I see where you're coming from, although I find it rather dispiriting, in that this point of view seems to be arguing against exploring and understanding the universe of different programming techniques.

It would perhaps be instructive if you could enumerate or point to what you consider to be a good set of concepts to work from. Clearly there are some absurd answers ("it's all NAND gates in the end"), but I don't imagine that's what you're thinking. Would you include functors? applicative functors? Different forms of memory management? APL/R/Numpy-style arrays? setjmp/longjmp?

matfilon Essential C (2003) [pdf]

I'm going to argue that there is an objective cost, and that is the length of the code. To me, there's a massive win in being able to take in the whole of an algorithm on a single screen or sheet of paper, and using two statements to do something that can be idiomatically expressed in one is in direct opposition to that. I get the feeling that there are (at least) two camps here that can very easily talk past one another. In my experience, "succinct-code" advocates care about readability just as much as "avoid-language-specific-constructs" advocates. They just have different experiences of what maximally-readable code looks like.

matfilon New Office Hours Aim for Well Rested, More Productive Workers

I thought the software world had generally agreed that adding extra people to something that’s running late is rarely the right answer.

matfilon New Office Hours Aim for Well Rested, More Productive Workers

One of the barriers to seeing more of this is the current focus on ”team-ism”. In the technical world, practices like pair programming and daily stand ups are big drivers of regular working hours in a field that was historically one of the better ones for individual flexibility.

matfilon Ask HN: If you were to switch career, what would you do?

Some form of agriculture is pretty appealing. More scope for being outdoors during daylight hours, and (somewhat) more tolerance for people who prefer to work alone.

The money side of things doesn't look great, though.

matfilon How to Keep Your Job as Your Company Grows

The CEO saw a problem and clearly communicated it -- you've gotten results but cannot explain how or why, and that isn't good enough going forward

That is clearly the CEO's point of view in this case, but it's a view I find rather perplexing. It leaves no room for intuition and good judgement. Potentially, it can force people to try and write down explanations of stuff they are not actually confident about, which just end up confusing whoever comes next.

matfilon Agile won the war but lost the peace

Scrum isn't the only offender. By-the-book XP is pretty rigid about some things, too (collective ownership and pairing in particular).

Agree that the consulting/certification industry makes things worse. Again, that overlaps with the signatories for the original manifesto.

matfilon Agile won the war but lost the peace

I agree there's a mismatch between the Agile Manifesto and most of the concrete methods described as "Agile", especially when it comes to how much individuality is valued. I am not at all convinced it's fair to blame this entirely on the methodology side. The eXtreme Programming book was published in 1999 (and had been talked about before then). Scrum is a little harder to pin down, but a book was published in 2001 (around the same time as the Agile Manifesto), but the ideas were definitely circulating before that. There were other concrete methodologies which fed in, _e.g._ Alistair Cockburn's "Crystal" methods, which seem to have faded away.

In any case, the people pushing the methodologies overlap very substantially with the people who originally signed the manifesto.

matfilon Ask HN: What makes for a world-class software engineer?

the solutions she comes with are easily explained and understood by everyone working on the codebase.

As a guideline, that's not terrible. As a hard and fast rule, it seems almost the definition of "lowest common denominator".

Taken to extremes, it can also preclude working with people who aren't generalists but have a really strong niche.

matfilon Ask HN: How to hire when your company and Glassdoor reviews are genuinely bad?

Precisely.

matfilon Ask HN: How to hire when your company and Glassdoor reviews are genuinely bad?

There is no agile, no source control, no meetings

If you stop there, it really doesn't sound so bad... Is there a way to present this as an opportunity for reasonably experienced introverts to "own" something without too many interruptions? Or is there enough incidental stuff that it doesn't work like that in practice?

(The "no source control" would probably bug me a bit, but presumably not much stopping someone running their own?)

matfilon The Adam Test: A Few More Steps to Better Code

The suggestion that managers should have >10 direct reports doesn't convince me. Maybe 30-person reporting groups can work in places where everything else is precisely right, but in most environments this will be a recipe for a power vacuum where people are incentivised to start acting as de facto managers. And I'd sooner have one manager (who, ideally, I had some choice in via picking a job or assignment) than several pulling in different directions.

Most of the rest is spot on, though.