Hacker News Reader

Comment by lordnacho | Hacker News Reader

There's feeling like you're getting things done because you're on a coding roll, and then there's feeling like you're getting very little done because you're still organising the project in your mind.

I don't think the two can be separated. Being stuck and being moving are dependent on each other.

A lot of the time I'm frustrated because I haven't quite figured out how the code should look. It takes a long time, a lot of chopping and changing, before you come upon a structure that you feel comfortable building on.

When you do get to that point though, it feels easy. Everything you write makes sense in terms of your new structure, and there aren't so many awkward kludges. The only thing is this period can be brief, because when you're fast, you get to the next problem sooner. You'll find higher and higher levels at which to view your code, and at each level you'll need to do some organising.

View on HN

> Steve McConnell in Code Complete (a book which criticizes the widespread use of the waterfall model) refers to design as a “wicked problem” – a problem whose requirements and limitations cannot be entirely known before completion. The implication is that it is impossible to get one phase of software development “perfected” before time is spent in “reconnaissance” working out exactly where and what the big problems are.

https://en.wikipedia.org/wiki/Wicked_problem

I used to be an architect before I became a programmer, so since I started programming I noticed I hag a big advantage over my peers when it comes to the high level designing and structuring a program.

Thing is, the more experienced I become at programming, the less of that I end up doing. I more and more tend to break everything down into tiny parts that can all work independently and be composed into bigger bits. Most of my career I've used OO languages, especially C#, but nowadays I usually avoid using a lot of the features of OO, like inheritance, and just try and make everything from tiny little methods (functions) big things are just made from several of those methods in sequence and really big things are just made from several of the big ones.

From a development perspective it means I can just go ahead and start writing useful little snippets of code and start composing them together into bigger and bigger features as I go. So, I'm switching from a top-down style to more of a bottom-up one.

It's always interesting to me to see how various people discover the basic advantage of function-oriented programming on their own.

There's also eg the copy-on-write filesystems, and git---whose main on-disk data-structures are conceptually immutable despite being implemented in C.

You might enjoy reading "Out of the tarpit" (https://github.com/papers-we-love/papers-we-love/blob/master...), a paper that deals with approaches to master software complexity.

Funnily enough, I'm on page 30 right now.

Great! Did you start reading before I mentioned the paper?

TL;DR Composition vs Inheritance

Agreed. And I'm increasingly tending to think that the stuck-thinking-about-the-tricky-stuff phase is the part of the game I find most satisfying.

A lot of textbook management techniques seem hellbent on trying to force steady productivity instead of punctuated equilibrium. Not the recipe for a satisfying environment.

I once had a manager ask me to email him a progress report every day; and every hour or two, he'd make a point of interrupting me to ask me "so how's <current_task> going?"

Sounds like something straight of office space, but that was my life for a while. Least productive job I've ever had because of that (well, and the myriad other little toxic/passive aggressive behaviors he had).

He had a Stanford MBA too, which convinced me of how useless MBAs must be. Because if you make it through one of the top programs in "business administration" in the world and still manage like that, you might as well have an MD from Harvard and still believe bloodletting is a viable treatment for illnesses.

I once had a manager ask me to email him a progress report every day;

This seems to have become very nearly normalised in the guise of daily stand ups. Some would argue it's less intrusive if it's for "the team" rather than for an individual manager, but I'm not convinced myself.

and every hour or two, he'd make a point of interrupting me to ask me "so how's <current_task> going?"

Similarly, in environments where tasks are getting broken down into tickets that are only expected to take a few hours, there's a similar level of oversight (although hopefully a bit less disruptive than hourly shoulder-taps, I agree).

I worked for a startup that grew up around me. We started without any project managers and such and they got introduced as the team grew and grew. I would just make tasks like "figure out how to do X", "look into this framework Y", "write a really good SO post for the bug we came across in library Z" . Worked fine, tho the PM for my project was sound.

I'm at the first job I've ever had that didn't do daily standups and it's liberating. I've never been more productive at work.

Maybe once a week my manager comes by and asks me how something is going. I give him a high level sketch and a time estimate. He goes along on his way after that.

He's treating you like a cog in a manufacturing plant, which he can "optimize" at will. MBA programs often teach people that. He doesn't understanding creative work or thinking heavy work "appear" to be non-working but it's essential.

Why does asking how someone is doing mean you're a cog, or that you're in trouble if you're still doing research?

Part of what a supervisor does is track progress across a whole team so they can keep other parts of the group appraised.

Another important job is helping people make tradeoffs between perfect and done as the situation on the ground changes.

Both of those require asking "how's it going?"

> I once had a manager ask me to email him a progress report every day; and every hour or two, he'd make a point of interrupting me to ask me "so how's <current_task> going?"

Asking a developer's status progress everyday or every hour? That shows the manager has absolutely no clue how development works. Period. Developers don't need a manager to "help" them make tradeoff on a daily basis. Developers need managers to back the fuck off to let them alone to concentrate on the mentally taxing work at hand.

I guess the MBA is there to facilitate your professional development, not to make you more productive.

And what you have to do in order to look good to your manager or manager's manager's manager is different than what you have to do to be productive. Your boss was perhaps just doing the former?

Here are some possible explanation for the behaviour. There might be other urgent fires burning for the past week and he is getting nervous and trying to figure out whether he needs to reschedule. He also has to manage up and set expectations when the whole project is going to be done. He might be concerned you are gold plating an otherwise simple task. He might think you are stuck and trying to figure things out on your own. You could help him by letting him have a sense of where you are, and whether there is something more pressing that he needs to talk about. Perhaps he has access to people/equipment/money that can accelerate your work.

The manager in question, were he a good one, should also be able to clearly and timely communicate if any or all of these things apply.

"A lot of textbook management techniques..."

Can you unpack this? Would like to hear more.

"Textbook" was possibly more a nervous tic than a statement of fact -- I've not read a lot of management textbooks...

However, whenever I see generalist managers at work, there always seems to be massive emphasis on schedule risk and at least in organisation I've been in, the proposed mitigation is always regular status meetings (and perhaps other forms of check-in as well).

This seems to have been almost entirely normalised in the software world, particularly anywhere that's gone down the agile pathway: fine-grained tickets in an issue tracker (or possibly cards on the wall -- but haven't ever seen that one in action) and a daily standup with an explicit goal of making sure nobody is "spinning their wheels".

One problem is that 'agile' has been taken over by management types.

> However, whenever I see generalist managers at work, there always seems to be massive emphasis on schedule risk and at least in organisation I've been in, the proposed mitigation is always regular status meetings (and perhaps other forms of check-in as well).

I think the reason for that behavior is because they don't want to be caught unawares when some deadline is missed. In other words, one of the metrics they are measured on is meeting deadlines, which of course pushes schedule risk to the top of the pile. There's merit to that, but that has to be balanced with the quality of the product.

The blind spot for such managers is that constant check-ins and updates on progress too frequently interrupt the flow of people who need time to think things through. Adding pressure at the wrong point can possibly ruin the quality of the final product.

I have a completely different way of mitigating schedule risk: find the most difficult, unpredictable subproblem and do that first. I guess it's not quite fair to say that I've never seen a manager pick up on this idea, but it still doesn't seem to have become their first-choice strategy.

An experienced architect will always do this. Often the most risky subproblem is the one that is least understood (unknown unknowns), which needs to be investigated, even if it turns out not to be a great risk. In agile-speak this is called 'spike solution'. Also see lean architecture methods, such as:

- 'Just Enough Software Architecture', by George Fairbanks.

- 'Risk and Cost Driven Architecture', by Eltjo Poort.

Thanks for the explanation. I've got a working theory: most people, even managers, even lauded ones, don't know much about "textbook" management. They mostly manage how they were managed, some picking up a few things here or there.

It's recursive.

I've worked in businesses, started and scaled my own, and have also been a teacher (k-12). We all go to school for at least 13 years and internalize what "teaching" is. Most teachers' classrooms end up looking like ones they experienced even if the "textbook" lays out massively different ideas. It's the same problem as management.*

We all also work, and internalize some conception of "management." Thus, most manage they way they were managed.

Throughout my career I've worked with over a hundred different organizations. I can read about many more in the news and case studies. I see very little in practice that aligns with hardly any of the big ideas in management that I've learned from the likes of Drucker and Deming.

*It has not gone unnoticed that education is our first experience with management. Often it has Taylorist, Theory X, command and control roots. In contrast, the great teachers I see have a lot in common with great managers and management theory (see Drucker, Deming).

I have "management" in my degree title, from a world famous uni. Basically a good taste of an MBA, since an MBA there is a year.

Very little of a management course is about how you treat people. If anything, you are left with Taylorism and the lingering question of how it relates to knowledge workers. Because Taylor was basically measuring factory workers' performance, whose contribution is to do some repeated action over and over. If that sounds like treating someone like a robot, it's because it is.

This is not to say nobody has thought about this. HBR will run an article now and again about HR issues. But there's nothing especially compelling where you'd be able to find a root cause, find a specific solution, and implement it. If it was, management wouldn't be magic, it would be engineering. And the practitioners would not be paid enormous sums for doing the impossible, they'd be paid moderately well for being ordinarily competent.

Most of the things on the course are really not that different from reading the FT regularly. So-and-so company found their product wasn't appealing to young people, so they tried X and it was a massive success. Doesn't tell you what to do if you were to run this firm, but after you've read a few you'll think you know. Case studies are a case study in post-hoc fallacy.

Then there's a bunch of supposedly advanced financial stuff, which if you're an engineer you'll laugh at. Ratios, really? Interest rates? If you do a proper finance course there will be real things to learn (stoch calc doesn't show up much in engineering), but not in the business school.

And there's a few useful things, too, like the history of capitalism, but nothing that develops a proper intuition or method for a field of problems like engineering does.

Thanks.

Ultimately, I think I was referring to the Taylorist aspect.

There's also a philosophy that I've seen labelled as "teamism" and which seems to form the basis of methodologies like Scrum. I'm not sure teamism is quite the same thing as Taylorism -- but it shares the same distrust for individuals working on problems without near-constant oversight.

Scrum has elements of Taylorism: team members are treated as interchangeable cogs to be assigned units of work and it has a crappy "productivity" measure built in (velocity).

I don't measure velocity in the scrum team I coach. And people's skills are not interchangeable but we do want most of the team member to be able to perform the easy stuff. A front end developer is not interchangeable with a backend developer. Having a task card about thinking through a design is always welcome. We use standup to have face to face conversations.

> And the practitioners would not be paid enormous sums for doing the impossible, they'd be paid moderately well for being ordinarily competent.

That's an awesome description of where we should move management to, hopefully. (Same for programming, marketing etc.)

This just, kind of blows my mind. What is management if not people? I mean Drucker's very definition of management is the idea of organizing a group of people to drive towards a common aim where you learn how to make each individuals' strengths effective and their weaknesses irrelevant.

Deming was adamant that psychology had to be a pillar of management. Why? Because people!

I'm curious then, who were the authorities/what were the theories (if any I guess) that were used for your management degree?

- Also, why am I talking about Drucker and Deming? Because if I drew a family tree, I could trace at least some aspect of nearly any management idea today back to them (lots of amalgams out there these days). There is one big caveat though, lots of management practices today have neo-Taylorism embedded into them that most people are unaware of.

> I'm curious then, who were the authorities/what were the theories (if any I guess) that were used for your management degree?

It felt like a very sporadic hodge podge of names. Porter's five forces, tech cycle, a load of case studies.

That's looking back a decade later, so maybe I'm missing something.

But it all seemed very vague. I remember thinking how on earth did Porter get his name on a "theory" when really that's just common sense? A company is going to tend to have customers, suppliers, entrants, and substitutes, and internal rivalry. I mean why would you think otherwise? Also, creating those categories is no guarantee that you're not going to miss out something.

If anything I've learned more about management from reading agile type stuff like Scrum, because those kinds of things are usually grounded in experience from a specific industry, with specific pain points and specific solutions.

> I remember thinking how on earth did Porter get his name on a "theory" when really that's just common sense?

This is how I've always felt about "De Morgan's Laws". There are two, and they state:

1. If it is not the case that two things are both true, then at least one of those things is false.

2. If it is not the case that either of two things is true, then both of those things are false.

(Actually, they are logical equivalences, so they also apply in the other order -- "1b. If at least one of two things is false, then it is not the case that both things are true.")

I'm pretty sure both of those "laws" were known well before the nineteenth century.

> Being stuck and being moving are dependent on each other.

Yeah, but in times of being stuck, it's much easier to get distracted and procrastinate.

Some amount of distraction is probably helpful. Once you have gathered all requirements and have thought about the problem for a while it is good to let it marinate for some time. You will often have moments of insight seemingly out of nowhere while you are e.g. going out for a walk.

Agreed. I often figure out a solution to a problem I'm having as soon as I stand up from my desk!

> Yeah, but in times of being stuck, it's much easier to get distracted and procrastinate.

A bit, but I tend to do directed procrastination. Go the gym, do some research on a different problem, write some emails, etc... As soon as I stop actively thinking about the problem a solution will come.

Another solution (and this works well with coding and writing) is just to start coding/writing. I'm writing an article now for a newsletter, and the top of my document is a bunch of stand alone sentences that eventually lead to a full article.

In programming, I'll often do the same thing and just start solving the problem even if I know it's not the right solution yet. Usually this leads me to a better understanding, and eventually the solution.

Directed procrastination works for me too. I usually hate admin type of work; sorting out my room, doing the laundry, responding in social media (yes, that counts too..)

But when I hit the inertia part of the productivity cycle, this saves me. It's always better to do something than just being stuck. And while I mechanically do those tasks, my head also gets in order, I start dreaming and slowly, I'm on the roll again.

When the right time comes, I slide back into the 'real' work. I can't quite regret for 'wasting' that time, because usually the reward is a new perspective, and the ideas that come with it.

Shrugs, we're not machines.

> As soon as I stop actively thinking about the problem a solution will come.

The book 'Hare Brain, Tortoise Mind' has a good explanation of how that works, what it's good at and what it's not.

I get a lot of side chores done with directed procrastination. But, what works for me to get the main task done is to just open the IDE even without a goal. Instead of "Ugg... I need to make X work today...". Just open the editor and do anything. Refactor a function. Comment something. Whatever. Once you get started, it much easier to continue.

My problem is when I open the editor and refactor a function, I start finding other functions that need to be refactored, then finding even more refactoring opportunities from those, recursively, forever. At some point I need to stop refactoring and start producing something new...

The thing I find works better than anything else is to write some code that works, even though I know it's far from the "right" design.

Once you have concrete working code, it's much easier to organize it in ways that make sense than trying to visualize everything beforehand.

As a young programmer I was taught to carefully design code before starting to write it. It kinda blows my mind that now I design it after writing!

That works for me too. I'm originally a lawyer and a decently competent writer and that's also how I approach papers or briefs. Writing is how I think and organize my thoughts so there's no more efficient way for me to design an overall architecture, whether in code or English, than just by starting to write. Once I start to get a grip on the parameters and pain points, I'll circle back and outline the higher level. My brain just works better from a bottom up starting point. Writing and coding are just formalized ways of thinking so sometimes you have to make concessions to your own brain's idiosyncrasies.

bottom-up is hardly a shameful idiosyncrasy. top down has a tendency to fail by imposing an inappropriate structure, and missing important details. every discussion i can remember ends up recommending switching directions repeatedly.

i start on the up-stroke myself, always worked for me

Yeah, I write a lot that way too, probably influenced by my programming habits.

I read somewhere that Neil Gaiman considers himself only a decent writer who is an extremely good editor. Which is to say, he starts writing a simple draft, and then changes what's wrong with it, over and over.

The trick to this model is being good enough at figuring out your organization of code that when you get to the easy part of implementation, you don't happen to discover you made a bad assumption earlier.

Reply on news.ycombinator.com