the bad guy here. I am evil and anti-innovation and closed-minded. How
dare I not scrap an entire project and
start over!? I’ve been through all of
the above time and time again.
The sad thing is, that developer
probably could have made a lot of
useful contributions. Sometimes
we come across incompetent developers, but a lot of times they’re actually great from the technical perspective; what they’re lacking is an
ability to microtask.
Developers jumping onto new
projects need to know how to break
down changes into small, digestible
chunks and then deliver them incrementally. Instead of pushing out one
huge chunk of changes or trying to
completely upend the entire project,
they need to set their sights lower. As
an experienced and successful architect, I’m not going to allow someone
to completely implode a project in
their first week.
Maybe I’m evil. More likely, the developer has been struck with a case of
fatal enthusiasm. Although they want
to do the right thing, they are way too
eager and overly zealous. Every fix has
to be implemented in one pull request
and there’s no time to wait. Any incremental improvements simply won’t
be acceptable. Remember, in their
view, time is running out and the project is only weeks from failing anyway.
So why don’t I just step aside and let
them fix the code the way they want?
Maybe they’re simply a better architect
then me. But here’s the thing: being a
successful architect requires microtasking. As an architect, you have to
manage changes, and you have to implement them gradually. This is a basic
necessity in a dynamic, collaborative
The moment a developer comes to
me and tries to upend the entire project just a few days in, I already know
they are going to struggle with incremental change. That means they’re going to struggle in the architect’s seat,
so I can’t exactly hand over the keys to
the whole venture.
So no, you are not being evil or
closed-minded when you reject hazardous enthusiasm. You are being
prudent, wise, or whatever you want
to call it. Most importantly, you’re being a good architect.
A Design Perspective
June 9, 2019
Computational thinking was popularized in a March 2006 column in
Communications by Jeannette Wing. In 2010, she
published a more concise definition (see
her article about the evolution of these
definitions at http://bit.ly/2Xwr1Nr):
Computational thinking is the thought
processes involved in formulating problems and their solutions so that the solutions are represented in a form that can
be effectively carried out by an informa-tion-processing agent (Cuny, Snyder, and
I have been thinking a lot about
this definition (see the BLOG@CACM
from last September at http://bit.ly/
2S437aS, and my April blog at http://bit.
ly/2YBljuV). This is a definition most
people can agree with. The problem is
when you use it to define curriculum.
What does it mean to represent a problem in a form that can be effectively
solved by a computer? What do we teach
to give students that ability?
Computers are designed. The problem form changes. We can make computers easier to use.
Human-computer interface designers
and programming language designers
are all about making it easier to represent problems in a computable form. A
good user interface hides the complexity
of computation. Building a spreadsheet
is much easier than doing the same calculations by hand or writing a program.
I have been digging deeper into the
literature on designing domain-specific
programming languages. The empirical research is pretty strong. Domain-specific programming languages lead
to greater accuracy and efficiency than
use of general-purpose languages on the
same tasks (as an example, see http://bit.
ly/2NHhFPh). We are learning to make
programming languages that are easy
to learn and use. Sarah Chasins and
colleagues created a language for a specific task (Web scraping) that users could
learn and use faster than existing users of
Selenium could solve the same task (see
the blog post at http://bit.ly/2XPd9Sx).
So, what should we teach in a class on
computational thinking, to enable stu-
dents to represent problems in a form
that the computer can use? What are the
skills and knowledge they will need?
˲ Maybe iteration? Bootstrap: Algebra ( http://bit.ly/2YMinvK) showed that
students can learn to build video games
and learn algebraic problem-solving,
without ever having to code repetition
into their programs.
˲Booleans? Most students using Scratch don’t use “and,” “or,” or
“not” at all (see the paper at http://bit.
ly/2L8ORwL). Millions of students solve
problems on a computer that they find
personally motivating, and they do not
seem to need Booleans.
Our empirical evidence suggests even
expert programmers really learn to program within a given domain. When expert programmers switch domains, they
do no better than a novice (see the post at
x http://bit.ly/2NEZidz). Expertise in programming is domain-specific. We can
teach students to represent problems
in a form the computer could solve in a
single domain, but to teach them how to
solve in multiple domains is a big-time
investment. Our evidence suggests students graduating with a four-year undergraduate degree don’t have that ability.
Solving problems with a computer
requires skills and knowledge different
from solving them without a computer.
That’s computational thinking. We will
never make the computer completely
disappear. The interface between humans and computers will always have
a mismatch, and the human will likely
have to adapt to the computer to cover
that mismatch. But the gap is getting
smaller all the time. In the end, maybe
there’s not really that much to teach
under this definition of computational
thinking. Maybe we can just design away
the need for computational thinking.
I wonder how well Khan Academy’s approach
to teaching computational thinking works,
since it seems to be more interactive and
can be connected to other skills (if there are
courses for them): https://www.khanacademy.
Yegor Bugayenko is founder and CEO of software
engineering and management platform Zerocracy. Mark
Guzdial is a professor of electrical engineering and
computer science, and engineering education research, in
the College of Engineering, and professor of information in
the School of Information of the University of Michigan.
© 2019 ACM 0001-0782/19/9 $15.00