matfil

8 ms·

31.
by matfil 8y ago
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?
32.
by matfil 8y ago
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 choice
33.
by matfil 8y ago
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
34.
by matfil 8y ago
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
35.
by matfil 8y ago
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,
36.
by matfil 8y ago
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.
37.
by matfil 8y ago
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
38.
by matfil 8y ago
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, see
39.
by matfil 8y ago
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"
40.
Responsible Autonomy(en.wikipedia.org)
1 points by matfil 8y ago|0 comments
41.
Cooking your Software(medium.com)
1 points by matfil 8y ago|0 comments
42.
by matfil 8y ago
Yes. The one strange thing is that it seems to have caught IBM somewhat off-guard.
43.
by matfil 8y ago
That may be true, but immediately makes me think of Rich Hickey's "constants matter".
44.
by matfil 8y ago
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
45.
by matfil 8y ago
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 mono
46.
by matfil 8y ago
Thanks, that's a pretty interesting take. (Also a reminder that we're probably going to lose some interesting stuff when Google+ goes kaboom...)
47.
by matfil 8y ago
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.
48.
by matfil 8y ago
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 functi
49.
Programmer as wizard, programmer as engineer (2018)(tedinski.com)
166 points by matfil 8y ago|74 comments
50.
by matfil 8y ago
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. Pe
51.
by matfil 8y ago
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 condition
52.
by matfil 8y ago
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 ins
53.
by matfil 8y ago
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 stateme
54.
by matfil 8y ago
I thought the software world had generally agreed that adding extra people to something that’s running late is rarely the right answer.
55.
by matfil 8y ago
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
56.
by matfil 8y ago
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.
57.
by matfil 8y ago
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
58.
by matfil 8y ago
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 wit
59.
by matfil 8y ago
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
60.
by matfil 8y ago
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&qu

More ›