
Mastering Programming (2016) - ternaryoperator
https://www.facebook.com/notes/kent-beck/mastering-programming/1184427814923414
======
d--b
Distillating years of experience in such tiny concepts is a bit harsh on the
reader. Without any concrete example, the advice could easily be very
misunderstood, or not understood at all.

Being a fairly seasoned developer myself, I kind of intuit what they mean, but
I could very well be projecting what I think I am doing right into each of
these, and conclude that I'm a master programmer... yay!

~~~
saltedmd5
This is the crux of the problem with a lot of software engineering culture as
it stands today - blog posts and talks frequently deliver abstract concepts
that only really make sense to people who have already grasped/discovered
those concepts.

The enlightened sit nodding along, while the unenlightened go away confused or
misled. Positioned this way, half-understood ideas frequently do more harm
than good.

TDD is a great example of this.

In this case, though, I think the article does a fairly good job - it
highlights productive ways of thinking that will incite useful self-reflection
("Do I do this? Could I do it better?") rather than half-communicating ways of
doing.

~~~
noxToken
> _The enlightened sit nodding along, while the unenlightened go away confused
> or misled. Positioned this way, half-understood ideas frequently do more
> harm than good._

I think this puts a lot of things into perspective for me. There will be a
blog post about some topic on HN, and it seems that everyone in the comments
just gets it. Yet I'm over here like, "Yes. I know some of those words. Maybe
I'll get the concept a bit more next year." Time passes. I'm still none the
wiser.

Functional programming was one of those weird topics for me when I first
started programming. It's pretty straight forward on the surface. Some X has
to go in. Some Y has to comes out. If it didn't originate inside the function,
then it does not get touched. Yeah but why? Who cares if I have a variable
outside of the function scope that gets modified? Didn't I declare it globally
specifically to have access to it anywhere? What's the point of all these
stupid rules when languages give me the ability to do so much more? But all
these people can't be wrong, can they?

So I shoehorned it in. I tried to make everything I wrote as functional as
possible. I started creating convoluted, over-engineered garbage that was
needlessly complex. Nothing felt right about it.

Then I _actually_ tried it. I sat down with a somewhat pure language to learn
functional concepts, and it clicked. I see why people extol the virtues of
functional programming. Like you've noted, not understanding the reasons
behind using functional programming can lead to a convoluted mish-mash of
cleverness that doesn't belong.

~~~
0xcde4c3db
Another problem that I've noticed with FP especially (although I get the
impression that OOP had this problem too when it was the new hotness, and I've
seen hints of it happening with Rust) is that there seem to be a lot of
novices who fall in love with the concept and start evangelizing it, convinced
that This Changes Everything. But they can't back it up with a lot of
practical experience, can't describe any caveats or limits to its scope, don't
have useful knowledge of the practical pitfalls, and so on. So when you bring
up something in your domain that seems like it would be difficult, they don't
have the foundation to say "this is how you solve that kind of problem" or
"yeah, that's still difficult". Instead they deflect or try to subsume it
under some vague principle that doesn't actually address your concern.

~~~
lgas
This is a problem with people, and not at all specific to FP.

------
vinceguidry
> Multiple scales. Move between scales freely. Maybe this is a design problem,
> not a testing problem. Maybe it is a people problem, not a technology
> problem [cheating, this is always true].

The key to this is realizing that once you decide a problem is at a certain
scale, the fix needs to be at that scale too. So you might have a data
problem, a code problem, a workflow problem, a design problem, an
architectural problem, a team problem, a project problem, an organizational
problem, a leadership problem, or an existential problem. (on the level of the
company)

Each type of problem has to be resolved by the resources on tap at that level.
You fix data problems by editing the data. You fix code problems by changing
code. You fix leadership problems by changing leaders. You fix existential
problems by changing jobs.

Becoming a more effective programmer involves understanding at a deep level
how everything interlocks and moves together. If you can't solve it at one
level, escalate to the next level and try to solve it there.

So you might have a code problem that you get pushback on fixing, this makes
it a design problem. So you get the stakeholders in a room to come to a
decision about what the code should be doing. If they can't come to a decision
then it's an organizational problem, so you go to the leader for a decision.
If he can't make a decision then you've got clues to a hidden leadership
problem at the company.

Problems should be instantly solvable once you get to the level they're really
at. You don't escalate though until you know enough about it to make a short
presentation to the next person in the chain.

Once you get above the workflow level, you're in the realm of politics.
Political problems are defined by the fact that multiple people in the
organization care about it and you need to get sign-off before you go and
unilaterally change something.

~~~
LrnByTeach
I would call this as The hierarchy of 'Troubleshooting Software Problems' ( as
a parallel to Maslow's hierarchy of NEEDS).

In order to fix a problem at certain Level, you have to go to 'Bottom Most'
layer which is ROOT cause of the problem.

>So you might have

a data problem,

a code problem,

a workflow problem,

a design problem,

an architectural problem,

a team problem,

a project problem,

an organizational problem,

a leadership problem, or

an existential problem.

~~~
vinceguidry
I think the best way of thinking about it is to split problems up across
levels. So if you have a code problem that you've worked out to be a design
problem, you now have two problems. The higher level one needs to be fixed
before you can fix the lower level one.

So the client complains about software behavior. You now have a client
problem. You isolate the issue down to a problem in the data. You fix the data
but the problem recurs. You now have two problems, a client problem and a code
problem, that's generating the bad data. You go to change the code but find a
design problem. You now have three problems. You have to solve the design
problem so that you know how to fix the code, so that you can then go tell the
client that his problem's fixed and here's a free month's service for your
trouble.

~~~
LrnByTeach
Well analyzed, this is how real-world 'software problems' are interlocked one
level to another and YES splitting problem across levels is way to go.

Here is one thing I gained from this Analysis. At times we encounter 'a Code
problem' partly caused by ' a workflow problem' and partly caused by 'a Design
problem' .

We may do a CODE patch fix for time being (ex. production bug), but having it
documented as '40% Workflow problem, 60% Design problem' will help to
consolidate all these 'contributing percentages' to come up with permanent
fixes at a Later time.

------
hota_mazi
Having spent entire days years ago poring through the JUnit 3 source code and
having been completely dejected by the quality of the code there, I don't
really trust Kent Beck to give advice on anything related to programming.

~~~
ashwinaj
> completely dejected by the quality of the code there

Please list a project of _equal complexity_ that has been written beautifully
from start to finish in your opinion. This myth of beautiful coding needs to
stop! Code is not a masterpiece from Van Gogh, it needs to ship. This
determines quality, not the usage of some obscure/mainstream/unreadable/oh-
look-how-cool-I-am idiosyncracy of the language. If you ain't shipping, it's
completely useless.

~~~
sloppycee
How about Google's Closure Library: [https://github.com/google/closure-
library](https://github.com/google/closure-library)

The code, imo, is some of the highest quality js I've seen. It is also
incredibly comprehensive and easily as complex.

High quality != shipping fast. They are separate quantities, it is easy to
have one without the other but very rare to have both.

~~~
ashwinaj
I'll take your assessment at face value (although a quick look at github
repos, it seems that junit is way larger).

My point wasn't to ship crap, it was about obsessing on quality over actually
shipping (and cutting some corners). This is something I learned at my first
job, we obsessed over quality and never shipped. Guess what happened? :)

------
kbuchanan
A lot of the comments criticize the article for being inaccessible to
beginners, and I think they're justified—without examples it's hard to know
what the author is talking about without having first passed through the fire.

Having said that, I think he's talking about a crucial part of programming
that beginners simply don't appreciate: how to break big problems into small
problems. In other words, how to unstick challenges (and even find joy in
programming) before writing a single line of code.

For example, make a list. Prioritize the items. Strike some. Put the simplest
at the top. Figure out which item causes you the most anxiety. Chop away at
the branches before attacking the trunk. Even intermediate developers often
fail to see that the best programming takes place in the form of a plan.

~~~
allenu
I would say don't work on the branches first. If something is simple and
predictable, it can be done later. (This also allows you to slowly converge on
a completion date since all the stuff you've put off is simpler and easier to
understand and predict in terms of schedule.)

Best to work on the challenging, unknown items first, especially if they form
the core that everything will rely on. It gives you time to work out the kinks
in the overall architecture. It's much harder to change those things later and
harder to predict how long it will take. It's also easier to mock out and fake
the branches.

~~~
kbuchanan
I think we're talking about the same thing from two angles—when a task appears
uncertain, it's important to isolate it. Sometimes, as you suggest, it's an
exploration (build the engine before the body to see it turn over), but other
times you can chip away at a problem, piece by piece, until there's no problem
anymore.

------
skywhopper
This looks like an outline for a potentially interesting article. But the
language is too vague to even know how to react to the ideas. What is meant by
"extracting a subelement"? "Make the problem easy" sounds great but could mean
lots of different contradictory things. So please write the articles being
hinted at in this outline, but as is, it's a bit tough to get anything from
it.

~~~
charlieflowers
I agree with you even though I disagree with most of the criticism of the
article here.

I feel like I know what Kent is talking about behind most of these points,
even though his words only hint at the deeper principle. He's trying to be too
brief, but I can tell there's depth there.

For many of the points, I had to think a bit, and then it clicked, "Oh, he's
talking about xyz. Yep, he's right. But his words don't really say that."

Kent Beck is not some AbstractFactoryStrategySingleton fool. I've learned a
ton of insights from him, and I've seen him articulate insights that I had
stumbled across and incorporated, but had not been able to articulate.

I'll grant you that some other talking heads often lumped in with Beck have
been overhyped and their rhetoric has run ahead of their insight. And no one
is perfect. But Beck usually has real insight behind what he is saying, and
this IMO is no exception.

------
greenyoda
Interesting discussion from 2016, when this was originally written:
[https://news.ycombinator.com/item?id=11858667](https://news.ycombinator.com/item?id=11858667)

------
gedrap
Extremely disappointed in this post to the point where I believe that the only
reason people upvote this is because it's written by Kent. A lot of it reads
just like motivational instagram posts. For example:

> Call your shot. Before you run code, predict out loud exactly what will
> happen.

M, okay, but what exactly do you mean by that? Or even poetic, kind of:

> Rhythm. Waiting until the right moment preserves energy and avoids clutter.
> Act with intensity when the time comes to act.

I have no doubt that each point has some very specific examples behind them
and knowing them could actually be useful. But right now, you can only guess
what was intended behind these #deep thoughts.

~~~
bcbrown
> > Call your shot. Before you run code, predict out loud exactly what will
> happen.

> M, okay, but what exactly do you mean by that?

I frequently do a variant of this, although not always out loud. One way to
debug a problem is to randomly vary various bits of the program until the
problem no longer appears. Another way to debug a problem is to use the
scientific method: develop hypotheses, then test those hypotheses with an
experiment. I think he's saying to develop hypotheses, and then run code to
test them.

edit:
[https://news.ycombinator.com/item?id=11859090](https://news.ycombinator.com/item?id=11859090)

~~~
darioush
I routinely use the "scientific method" to debug. But usually by then it's too
late: the code is too hard to reason about so I have to treat it like a
blackbox and "observe" its "responses" to the "stimuli" I'm changing.

------
twii
Good post with loads of valuable points.

This document clearly shows that "master" programmers focus on very different
things than a beginner might expect. A beginner can get really excited and
proud making something complex work without noticing the flaws. After years of
debugging your own code you'll find out that getting complex things done is
not really the issue, it is HOW it's being done that makes the difference.

Beginners tend to focus on new language features, premature optimisations,
having unnecessary strong opinions about wether using a for loop or map or
reduce etc.., using too many and buggy libraries, literally copy and use code
from others without noticing it's flaws, getting pride from writing complex
code that almost no one can understand, trying to beat the calculator, trying
to beat Google with your own memory, over estimating the value of linters, CI,
TDD, agile, what editor to use, etc.., etc...

All these things take up so much space and energy at the cost of what really
matters if you want to do what a master does: write bug free code that is easy
to maintain and a joy to read.

------
nafizh
'Ideas are like frightened little birds. If you scare them away they will stop
coming around. When you have an idea, feed it a little. Invalidate it as
quickly as you can, but from data not from a lack of self-esteem.'

This.

------
taneq
Random thoughts from an alright programmer:

Slicing: No. Cut the project into appropriate-sized slices. Cut big slices
into sub-slices. Hierarchy is your friend.

One thing at a time: Yes.

Make it run, make it right, make it fast: Yes.

Easy changes: No good changes are hard once you own the result. If a change
feels hard it's probably not good yet.

Concentration: That's one of two approaches. IMO either rearrange the code so
you only need to change in one place, or rearrange your change so that the
code only has to change trivially in any place.

Isolation: Depends.

Baseline: Yes.

Call your shot: Yes, but only because it means "know what you think will
happen" which means "understand the codebase". If you're working on someone
else's codebase, discard this and replace it with "try things and learn from
them."

Multiple scales: Yes.

Symmetry: You mean 'factoring'. But yes.

Aesthetics: We define beauty as solving problems efficiency. If it's ugly but
it's the best answer, we'll learn to think it's beautiful.

Rhythm: Yep. A time for all things.

Tradeoffs: Yes. You can't make a call til you understand the context.

Fun list: I guess that works.

Feed ideas: Never be afraid to ask what-if.

80/15/5 rule: Situational. If current low risk work is gravy spend 100% on
that. If not, dig into R&D.

------
jorgec
"Poor workers blame their tools. Good workers build better tools. The best
workers get their tools to do the work for them." Right now, i am finishing a
system that took me 2 weeks do develop. With the standard way, i should have
finished it around January of the 2018.

~~~
darioush
I wish your comment alluded a bit more to the details.

------
module0000
Programming is like anything else... it's a learned skill. Some people will
have unusual high aptitude for it, while others will have unusually low
aptitude for it. While it's fun to read existential abstracts of
programming(like this article), it's better(for me, and all my coworkers, from
every job I've ever had) to just _practice_. Learned skills are refined
through repetition. Learn from your peers, and practice, practice, practice.
No amount of reading blog posts, or "transcending logic" as the blog post
suggest, will make you one iota better at programming.

------
dabockster
> Facebook notes

Stopped reading right there. My experiences have led me to believe that 9/10
Facebook posts of this nature are purely for publicity's sake and not being
taken seriously by the author.

------
rf15
Seems too abstract to be of value to people who are looking to improve
themselves.

------
andreasgonewild
I find Beck to be mostly spot on, enjoyed his books on smalltalk and unit
testing back in the days. I get the feeling that he couldn't care less who is
a master according to what measure, he's just trying to make the best use of
his experience by doing and sharing, which is the the only thing that makes
sense once you go deep enough down the software rabbit hole.

------
rickpmg
Holy crap, his post was full of self-indulgent, non-actionable advice that is
totally unrelated to programming.

Anyone who says 'they get it' is likely just afraid they will be viewed as
stupid if they say they're confused.

Anyone remember the story of the "emperor's new clothes?"

------
doall
He talks about common patterns of master programmers, but does not define what
master programmers are, and why he thinks they are masters in the first place.
I really don't get the point of this article.

------
bitdiddle
"30\. In programming, everything we do is a special case of something more
general -- and often we know it too quickly."

------
z3t4
If you know you will be stuck working on something for a while, spend a little
extra time on each progression, like solving edge cases, performance issues,
compatibility, and writing automatic tests for regression. That way you can
spend more time on actually adding value, rather then catching fires and
debugging.

~~~
abuani
And if you're new to a team or a company, do not underestimate the value of
confirming documentation and test cases(if they exist!) and improving upon
them if it's possible. This helps in multiple ways: you gain a reasonable
understanding of the codebase through reading and testing; you are immediately
contributing value to the team by improving upon the process and making it
easier for you to onboard new people when the time comes; you gain the
confidence of your team by showing interest in details that may have been
overlooked for significant periods of time, allowing cruft to build up and
plenty more.

------
lnalx
For the open-web supporter:

From years of watching master programmers, I have observed certain common
patterns in their workflows. From years of coaching skilled journeyman
programmers, I have observed the absence of those patterns. I have seen what a
difference introducing the patterns can make.

Here are ways effective programmers get the most out of their precious 3e9
seconds on the planet.

The theme here is scaling your brain. The journeyman learns to solve bigger
problems by solving more problems at once. The master learns to solve even
bigger problems than that by solving fewer problems at once. Part of the
wisdom is subdividing so that integrating the separate solutions will be a
smaller problem than just solving them together.

Time

    
    
       - Slicing. Take a big project, cut it into thin slices, and rearrange the slices to suit your context. I can always slice projects finer and I can always find new permutations of the slices that meet different needs.
    
       - One thing at a time. We’re so focused on efficiency that we reduce the number of feedback cycles in an attempt to reduce overhead. This leads to difficult debugging situations whose expected cost is greater than the cycle overhead we avoided.
    
       - Make it run, make it right, make it fast. (Example of One Thing at a Time, Slicing, and Easy Changes)
    
       - Easy changes. When faced with a hard change, first make it easy (warning, this may be hard), then make the easy change. (e.g. slicing, one thing at a time, concentration, isolation). Example of slicing.
    
       - Concentration. If you need to change several elements, first rearrange the code so the change only needs to happen in one element.
    
       - Isolation. If you only need to change a part of an element, extract that part so the whole subelement changes.
    
       - Baseline Measurement. Start projects by measuring the current state of the world. This goes against our engineering instincts to start fixing things, but when you measure the baseline you will actually know whether you are fixing things.
    

Learning

    
    
       - Call your shot. Before you run code, predict out loud exactly what will happen.
        Concrete hypotheses. When the program is misbehaving, articulate exactly what you think is wrong before making a change. If you have two or more hypotheses, find a differential diagnosis.
    
       - Remove extraneous detail. When reporting a bug, find the shortest repro steps. When isolating a bug, find the shortest test case. When using a new API, start from the most basic example. “All that stuff can’t possibly matter,” is an expensive assumption when it’s wrong.
          >  E.g. see a bug on mobile, reproduce it with curl
    
       - Multiple scales. Move between scales freely. Maybe this is a design problem, not a testing problem. Maybe it is a people problem, not a technology problem [cheating, this is always true].
    

Transcend Logic

    
    
       - Symmetry. Things that are almost the same can be divided into parts that are identical and parts that are clearly different.
    
       - Aesthetics. Beauty is a powerful gradient to climb. It is also a liberating gradient to flout (e.g. inlining a bunch of functions into one giant mess).
    
       - Rhythm. Waiting until the right moment preserves energy and avoids clutter. Act with intensity when the time comes to act.
    
       - Tradeoffs. All decisions are subject to tradeoffs. It’s more important to know what the decision depends on than it is to know which answer to pick today (or which answer you picked yesterday).
    

Risk

    
    
       - Fun list. When tangential ideas come, note them and get back to work quickly. Revisit this list when you’ve reached a stopping spot.
    
       - Feed Ideas. Ideas are like frightened little birds. If you scare them away they will stop coming around. When you have an idea, feed it a little. Invalidate it as quickly as you can, but from data not from a lack of self-esteem.
    
       - 80/15/5. Spend 80% of your time on low-risk/reasonable-payoff work. Spend 15% of your time on related high-risk/high-payoff work. Spend 5% of your time on things that tickle you, regardless of payoff. Teach the next generation to do your 80% job. By the time someone is ready to take over, one of your 15% experiments (or, less frequently, one of your 5% experiments) will have paid off and will become your new 80%. Repeat.
    

Conclusion

The flow in this outline seems to be from reducing risks by managing time and
increasing learning to mindfully taking risks by using your whole brain and
quickly triaging ideas.

------
m3kw9
Engineering is basically how to be solving problems given constraints and how
to properly solve it. I think breaking down the problem in small steps is the
method to use to get you 80% of the work done in 20% of the time.

------
rattray
I believe this is a duplicate - and in any case should be labeled with (2016).

------
Dowwie
Make it run -> make it right -> make it fast

~~~
twic
This is good advice in general, and so it amuses me when i come across
problems which invert this order. Now and then, you can say "if we could do
this thing that currently takes time T in T/100, it would be a game-changer"
\- it would enable whole new approaches, businesses, etc. In that case, your
primary goal is to make it fast, and if often doesn't matter if it crashes,
fails, or gets a slightly wrong answer 10% of the time, so you start by making
it fast, then improve the code, then work on the improved code to make it
reliable.

~~~
d3ckard
If it currently takes time T, then it already runs and probably runs right,
otherwise you likely wouldn't care about cutting time. Rule still stands.

~~~
twic
No. It might take someone else time T to do it, and we don't do it at all. It
might take another program, whose codebase we are not going to touch, and
which does it in a different way, time T to do it. In the cases i am thinking
about, this was a new program, written from scratch, which did not go through
a "make it right" phase before being made fast.

------
microwavecamera
The tl;rd: Use common sense.

------
vesche
I'm sure I'd love to read this article, unfortunately I don't browse the
closed web.

~~~
rhencke
What do you consider the closed web to be? I'm assuming you don't consider
Hacker News part of the closed web, correct?

~~~
x0
The article in question is on Facebook.

------
justinmoh
How much is 3e9?

------
rcdwealth
For heaven's sake you could not choose better hosting website but the bloody
Facebook.

~~~
tangue
Side discussion : Discoverability of Facebook articles is non-existent. Kent
Beck other posts are quite interesting but to find them you have to go to his
profile, click on a mysterious "more" menu item and then you can select his
articles...

~~~
teddyh
And that’s only if you have an account on Facebook and is logged in. Everybody
else get nothing.

------
fiatjaf
facebook.com?

------
hkon
How does IQ and staying power factor in? I would think that this plays a
significant role as well.

------
the_common_man
What exactly is that picture? At first open, I immediately closed it thinking
it was nsfw. Or is that some ad?

~~~
lucideer
A more illustrative example:
[http://api.ning.com/files/XnTJa0dlfiK12NtEAkCqjcJ*yhP1-6ZXx6...](http://api.ning.com/files/XnTJa0dlfiK12NtEAkCqjcJ*yhP1-6ZXx6ov513PuN36X9CK7jQupVgvlr9f9rSd1nSK-
DACIGGRxnY3fbGpT3-WsV3vVs03/tortus3.gif)

