Hacker News Reader

Comment by carl_sandland | Hacker News Reader

Some things I've learned after 35 years;

  1. learn how to communicate: being a good developer requires as much (more?) social as it does technical skills. I would recommend formal training and practice.
  2. question all assumptions.
  3. there is no silver bullet (read mythical man month).
  4. fight complexity and over-engineering : get to your next MVP release.
  5. always have a releasable build (stop talking and start coding).
  6. code has little value in of itself; only rarely is a block of code reusable in other contexts.
  7. requirements are a type of code, they should be written very precicely.
  8. estimation is extrapolation (fortune telling) with unknown variables of an unknown function.
  9. release as frequently as possible, to actual users, so you can discover the actual requirements.
  10. coding is not a social activity.

View on HN

Spot on - 40 years of coding, 33 professionally, and your list resonates with me. I'd also add: write code in tiny pieces where you don't do the next piece until you're confident the current piece works. I get fidgety when I have a bunch of code I don't know works.

Mostly, though, I can tell a grizzled veteran (and I've known some that hardly had any years under their belt, it's all in the soul!) because they rarely claim to know The Answer, and have a weary self-confidence that, even though they don't know how, they will get the job done.

Last year, after experiencing several individuals that fit the term, I came to calling some people "Medium Developers" - generally falling in the 4-8 years of experience, that get much of their knowledge from Medium articles, and believe the dogma wholeheartedly. Complete lack of nuance in all things, and are very evangelical about their dogma. Shitty managers are enthralled with them, and the code written (slowly) in such situations is horrific. "Throw it out and do it the Right Way (tm)" is the mantra.

Honestly, the blog post in the OP sounds like a Medium Programmer. They're worship of TDD is one symptom!

"I don't know, but we'll figure it out" is what I like to hear, versus, "This is how it Must Be Done!"

> write code in tiny pieces where you don't do the next piece until you're confident the current piece works. I get fidgety when I have a bunch of code I don't know works.

I think getting to this point really helps with the "flow" issue ("coding is not a social activity"). The more you can isolate small steps, you can more easily weather interruptions.

> They're worship of TDD is one symptom!

My suspicion is that this person is very good at writing the tests, at the right level of isolation and detail, and that watching them work would feel less dogmatic that the text of the blog post suggests.

> "I don't know, but we'll figure it out" is what I like to hear, versus, "This is how it Must Be Done!"

I've had this argument multiple times recently. Usually when I say the former the response is something like "But how can we really estimate it or plan it before we know exactly what we're doing"

Writing overly detailed requirements without coding gives me the same feeling of fidgetiness you mention. My attitude is "Plans are worthless, but planning is essential" , and you have to cut off design at some point because the risk (that you discover something in coding that invalidates the plan) outpaces the value (of knowing what you're doing).

Reminds me of another problem I've seen recently - an obsession with writing code that is "overly correct". There are times where a small change of a few lines accomplishes a thing but produces some undesirable side effect - it breaks an expectation somewhere, for instance. But the alternative is rewriting a huge portion and adding a ton of code and adding complexity as a result, even if the methods and their responsibilities are more clear.

"Throw it out and do it the Right Way", in other words. We've become very conditioned (especially mid-career) with focusing on never allowing tech debt and doing it the right way. But sometimes you actually add complexity in trying to achieve perfect cleanliness. And in fact, even if the resulting code is slightly less complex, there is a lot of risk in the rewrite.

At my stage of my career - 15 years - the biggest conflict I see is between business that wants estimates and the inherent unpredictability of writing software. Business wants the list of things I'm going to get done, meanwhile I want priorities. Are you able to say "Hey, this thing I thought might take a week is actually a quarter long project, should we set it aside knowing that?" Often the org is simply not flexible enough to handle that (or handle scoping it down so it can get done in a reasonable amount of time).

I'd almost say what you describe is the sign of a mid-experienced manager, too. They've realized it's important to shield their team from some organization problems so they can write quality code (moving past the "yell at them until it gets done" phase). But they haven't really learned how to get past the mid-level engineer obsession with beautiful code, or to handle the general complexity of the inherent clash between business goals and engineering goals - they've gone full towards the engineer side of that spectrum.

This is unreadable on mobile.

I'm also having a hard time swiping the text. So ahead of the poster:

1. learn how to communicate: being a good developer requires as much (more?) social as it does technical skills. I would recommend formal training and practice.

2. question all assumptions.

3. there is no silver bullet (read mythical man month).

4. fight complexity and over-engineering : get to your next MVP release.

5. always have a releasable build (stop talking and start coding).

6. code has little value in of itself; only rarely is a block of code reusable in other contexts.

7. requirements are a type of code, they should be written very precicely.

8. estimation is extrapolation (fortune telling) with unknown variables of an unknown function.

9. release as frequently as possible, to actual users, so you can discover the actual requirements.

10. coding is not a social activity.

A bit OT, but I really wish HN supported markdown in comments - with the current system, I often find it difficult to format as I intend, especially while on mobile.

Could you please elaborate the "coding is not a social activity" or offer a reference. Thank you very much in advance! reply

np. The "Stuff" that surrounds coding is very social (point 1), but the actual activity of writing code is very inward focused and ideally uninterrupted. The idea of FLOW is a very real thing, its very zen: hours just fade away until you look up and everyone has gone to lunch. I'm tilting at the open office windmill and idea that whilst I'm actually coding, I need to interact with others.

Being a "Developer" (planning, designing) is very social, however writing the actual code, for me at least, is a very inward activity and suits my quiet personality. The problem here is that non-coders don't understand this and it can cause a lot of friction when working in the usual group office environment.

It's a catch 22, people want me to code for them, but then they have a problem with me socially when I'm trying to code ;)

I agree with that and can also relate to this point (as I experience exactly this in my current project) my colleague already complained about being interrupted many times already. The problem is that the non coding colleagues want to ask just a 'quick question'.

Thanks for the quick reply.

What do you think of pair programming and the more extreme nature of it called mob programming. Have you seen either of those two things work well in any context?

Pair programming was never intended to be a full time mode of development. Half an hour once a week (or whenever) is good enough, and can help with mentoring junior developers. But it is really moronic to do that full time.

"intended"? By who? Based on what?

I worked at companies that had full time pairing and it worked well.

When you tried full time pairing, what were the issues you observed that made you conclude it was "moronic"

.. by the people who started it and popularized it. I have never tried it full time because it's obviously patently moronic to do it that way, and would destroy all enjoyment of the job. I have worked with highly talented developers and can not recall any one of them wanting to pair full time. I have received huge benefits from occasional pair programming with senior developers in my less senior days. However, I need to try full time pair programming as much as I need to try jumping into a fire to verify that it's not a smart idea. If my employer forced me to do that I would quit on the spot.

I’ve only seen mob-programming to be adopted by teams of junior-slackers, but YMMV

Some thoughts;

1. At some point in the 90s there was an "Extreme Programming" movement, or XP as it were. I distinctly remember the dogma built up around this, to the point where I started being forced to do pair programming in a formal sense, all day. Thankfully I just quit. I guess I prefer my coding to be less than extreme.

2. As others have mentioned, short term pair programming (never works >2 imo) is an excellent way of transferring knowledge (a model) to someone else, or to make progress on complex problems when you are stuck (the rubber duck effect is real).

3. I'm afraid I really must be getting old as I've never heard of "mob programming", and to be frank I've spent the last hours being horrified that such an idea exists. I guess in a way code reviews can be like that sometimes. lol.

I've done non-forced pair programming for suitable tasks that were really math heavy in a controll algorithm where I essentially double checked the math. Worked that time really well but always doing it would make me hate my job.

Yeah but just about nowhere did XP properly, though many places claimed to in the late 90s, early 00s whenever it was the extreme hotness. It was one of those peculiar cults everyone talked up, but just about no one understood or had even read the book.

One place I was at did everything, including onsite customer etc. In context pair programming managed to stay enjoyable for the entire time and they didn't seem to have high turnover. It actually kept on feeling more productive. I was there around a year (contract). I never encountered it again so can't comment if that was sheer luck or the people (or project) they happened to have...

There was a spell when every job ad seemed to want to claim it, but basically picked pair programming and two to five of the bullets and handwaved or ignored the rest. Or merged it with plenty of old school waterfall project management, Gantt charts, random bits of UML or some other tangent. I guess I'm not surprised so many ended up hating everything around XP and pair programming as it took many forms. It made for a few surreal interviews after that one encounter of an employer who'd adopted it fully and properly.

Any practice which almost no one gets it right, may be there is something inherently wrong about the practice that so many smart people are failing to implement it right.

In my experience pair programming works wonderfully for short, intense and complex problem solving scenarios. The extra pair of eyes and a second brain gnawing at a nasty problem is a good way to augment each other's capabilities.

In fact, I dare say that pair debugging is where the practice really shines. Doing it all the time, for all tasks? That won't fly.

Pair programming works if used as a mentorship. You’ll need to have a senior dev and a less experienced one.

But I guess this is but the original intent of pair programming

This is off-topic, but I have never experienced the "flow" you mention but I've had a decent career so far. I'm not the best or anything but I've done well in terms of promotions or projects shipped.

I've never lost track of time coding like you say - I stop at 12:30pm for lunch and then at 5:00pm to go home. I've always wondered if I am doing something wrong or maybe I just like programming enough as a job.

Being able to enter that state isn't reliable even for people who do it often. I've never been able to do it at work, it happens somewhat often when I'm doing home projects if my environment is suitably quiet.

I've found that I experience a kind of embarrassed reluctance to fully commit all my attention to something while I'm at work surrounded by people, that prevents it for me.

I get it reasonably often when I'm coding my projects late at night, when there's nobody there to bother me. The downside is that it messes with my sleep, since I'll start at midnight, write some code, think "okay I need to go to bed by 1 because I haven't been sleeping well" and I look and it's 5 am.

I agree, I've heard of 'the flow' but it's never happened to me.

Perhaps related, perhaps not, I never 'sink in' to films I'm watching. My old GF seemed to be able to, but I'm always on the outside looking in, never immersed. I wonder if that's linked.

I’m the person you replied to - I’m a big film fan but I have the same “issue”. The only time I can get immersed is at a movie theater and even then it’s rare (last time I was immersed it was with Parasite). But again, I enjoy the film and am able to remember all of it so not sure if it’s a problem.

I'd not intended to suggest it was a problem, only that it was perhaps related to the inability to get into the flow. Merely an observation.

Parasite the korean film?

A job is for wage. You don't mention programming as a hobby. Flow happens when you're personally engaged and truly interested in the solution you're building. This happens more on personal side-projects than at work, where the modern work-environment makes sure to interrupt us as much as possible. If programming is just the objective of codifying some business logic for a company, you won't become personally engaged. Also, non-trivial and complex solutions may break flow, as you have to walk and think more. Flow is more for those passages of coding where you jot down simple, but lengthy solutions, then realize a simple refactoring will DRY up the code. Then after 5 such iterations with some YAGNI, you've skipped lunch that day! You became engrossed in the work itself. Music may help, but becomes a distraction for any deeper design-thoughts.

Nothing magical about flow, but feels very productive even though one might be working on the wrong solution all along! For gaming industry and huge codebases, programmers absolutely need to get into flow in order to manage to complete it all in time.

To enter a flow state you need to be working on something moderately challenging, but within your ability. It has to be a task that takes concentration and will take at least an hour to complete. You need to be relaxed and cannot have any distractions around you. It takes a good 15-20 minutes to get into a flow state.

For me flow is very pleasant but I don't get to experience it often, maybe once a month. It always feels very productive. I can be in a light flow state where I am still slightly aware of my surroundings, but on rare occasions I have experienced deep flow where I am aware of nothing but my internal monologue and the code. I daydream about being able to get into that mode sometimes.

I was going to type a more detailed response, but the people below have done an excellent job already. The body has to be balanced, distractions at a minimum, the mind open and curious and the problem "not too easy and not too hard". I like to think of it as "chasing the white rabbit". One thing that can help is to write a detailed plan of what your coding session is going to achieve, with some stretch goals. If you do it right you will enter a cycle of achieving small goals leading to refactoring and bigger goals and then you.... look up and the whole team has gone to get Tacos without you again.

Sad to hear. Every job I've had I've been able to get into that flow. But Ive also always had my own office or work from home. 20+ years of doing this professionally and as a hobby.

My advice is to find some way to take some pride in the work you do and or change employers when that flow stops happening. life is too short not to.

Many artists are also similar, who experience flow in creating.

But then there are many successful ones who follow a schedule and still create amazing body of work. For example - Roald Dahl. Based on the notes in his books, he was someone who followed a daily time schedule and he did alright.

So, do what works for you I guess.

For me there are two big contributors to flow (and flow may not be the same for everyone): requirements are very well understood and willingness to code the requirements.

If it's boring or boilerplate it doesn't work. Otherwise, some kind of flow normally happens. I believe you require some amount of concentration hence the need to not be interrupted, and it has to be a bit challenging to require concentration.

An example would be an interview or college exam: you are pressured and needed to stay focused, yet the time passed very quickly.

Our minds work very differently... if you're good at producing results and enjoy what you're doing keep doing it :)

Some of us do most work in stretches of "flow" that involves disconnecting our minds form the outside world and from the people around us. We "go deep" like in a state of trance for stretches of time. We probably work faster, but we also need more and longer breaks between these stretches of hyperintense work. Others like you (maybe most?) can work while aware of time and their surroundings. It's good that we're different, each approach has advantages and disadvantages, we all discover what works best for us individually... just respect the needs of the people around you, let them work however fits them best!

As a "flow-er", the most important skill I've learned is how to be productive even when I can't get into flow. As a non-flow-er, you should probably learn the opposite: find tasks and ways of working that can help you discover "flow"... even if you won't experience it very often, it's worth experiencing it!

Not sure I agree with 6. I find that if you develop for reusability and you're a bit creative you can actually reuse a lot (though it might depend on how tightly you define "other contexts"). I have to say that functional programming plays a very important role in this though.

all reusability have limits! usually work is carried out to satisfy a set of requirements. as long as requirements are matching old ones in a different task then the product can be reused but in case there is deviation then alterations will be required to address the differing bits. we may predict future requirements and address those too through generalization but that must have limits as addressing predictions is by definition not certain, may need refactoring still in the future while using actual resources. even the stl of c++ needs rework as it does not address certain requirements or address outdated ones. no code will be reusable completely all the time, in fact only reusable if specific circumstances match. generally speaking generalization is impossible.

What formal training do you recommend for cultivating social and communication skills?

That's a really good question; I'd pay good money for developer focused communications training. Some practical ideas;

1. try to engage at work with more activities, you'd be surprised what activities you can help out with, or maybe arrange.

2. never pass up a customer focused activity, volunteer and push to be involved.

3. ask a sales or business guy at your company to be a mentor.

4. talk to random people beyond small talk (parties?).

5. read books (mileage varies).

Something like "toastmasters" for coders would be so cool.

Great list. (1) and (10) seem at odds, or alternatively are tautological; I think the important thing is to acknowledge that social and isolated modes are both required to develop software, and that getting the balance right is hard, and isn't the same for everyone.

Seems to take people a long time to figure out (4) and (6).

(2) and (3) and (7) really apply to most things.

Nice list. Thanks. I’m gonna clip that an ruminate on it a bit. I dispute 10 strongly, tho’. Our projects are largely built collectively, for collections of people and machines; use community derived patterns and practices; are typically too large to keep the whole thing in (human) working memory; are better with code-review.

> 10. coding is not a social activity.

I wish multiple tech leads I've interviewed with, here in Berlin, realised that. There's just so much cargo-culting around XP.

Sage advice from an obvious veteran in the field.

Reply on news.ycombinator.com