In conversations with people who are much smarter about education than am I, one idea that came up was this notion of foundational knowledge. To define “foundational knowledge” by analogy think of learning basic arithmetic. First you learn addition then subtraction, multiplication and finally you move on to division. I can’t claim to understand the underlying pedagogical theories but it seems to me that if a child hasn’t mastered addition there’s little point in him or her moving on to subtraction etc. And you sure aren’t ready for algebra if you can’t deal with basic arithmetic.

In the same way, I’ve often thought there should be some sort of basic curriculum for software developers. Some sort of foundational knowledge which must be mastered before one can progress to harder subjects. I’ve seen lot of places teaching “Principles of Object-Oriented Programming” while never concerning themselves with whether or not a developer can competently write a loop. To me being able to write a loop is the developer equivalent of being able to master addition. (Feel free to insert charges of me “gatekeeping” here.)

Now I know there are some folks reading this who will say that many developers will never need to concern themselves with writing loops. And that’s probably a fair criticism. However, some knowledge is foundational to other knowledge. Could a student of mathematics understand the notion of a summation if he or she didn’t understand the basic notion of addition?

Even beyond the question of certain pieces of knowledge being “foundational” there’s the question of thinking in a computational way. While human beings are capable of leaps of intuition (i. e. arriving at an answer while not having to process all the intervening steps) computers are not. In order to program a computer we need to tell it all the steps needed to reach a solution. In fact it’s the very human trait of glossing over non-essential details that makes writing software hard.

Let’s put this to a more concrete conversation. If I said to you I need a program to read a file of totals and find the largest dollar amount in the file, if you don’t think of using a loop (or some language library that contains looping logic underneath) you’re doing it wrong.

The pseudocode for such a process would look something like this:

Open file
Set dollar amount to zero
:start
Read line from file
Parse dollar amount from line
If dollar amount is greater than stored dollar amount
set dollar amount to new dollar amount
If next line is available go to :start
Close file

Now I would need to translate that into language specific calls but that’s essentially what I would need to do. Do I care about a File class (in that classic OOP sense)? Well depending on the language I may. Do I care how I store dollar amount (i. e. integer or float)? Again, depending on the language and the problem I may. But the most important thing is to think in terms of a loop to solve the problem.

Of course, my pseudocode doesn’t take into account any potential error conditions; hence it’s foundational and other code would need to be added to it.

My point is that basic sort of computational thinking is quite separate and apart from language paradigms (Imperative vs. Functional; OOP vs. Procedural etc) and it’s fundamentally harder to master in some way. If a developer cannot master something this basic though, he or she is bound to fail eventually because this sort of thing is going to come up. And even if the language’s library can hide the details from you, you still need to have a notion of what’s going on if you have to debug this.

If you want to be a better developer, first insure that you’ve mastered these foundational concepts of software development. This is not to diminish the difficulty of learning more advanced concepts; it’s simply to say that, to me anyway, too often developers leap to advanced ideas without mastering basic ones and their work suffers for their lack of mastery of basics.

(With apologies to Edsger Dijkstra)

I’ve suspected for a while that many of these coding boot camps and other “learn coding in an accelerated way” are turning out people who know just enough to be dangerous. I say this not to be mean or to denigrate these recent graduates; I’ve met a lot of them and they’re good, hard-working people. They’re genuinely trying to make a big career change and that’s always tough. But they come out of these boot camps with a superficial understanding of software development. Since I was training novice developers for a while I often tried to figure out better ways to train people to be software developers.

So lately I’ve been reading Felienne Hermans’ The Programmers Brain via the Manning Early Access Program. By the way, full disclosure, I am fortunate enough to count myself among Dr. Hermans’ acquaintances. Brilliant person and doing a lot to help us understand how to teach software development. One thing she mentioned in her book is retrieval practice. I have heard this term in other pedagogical literature. It basically means trying to remember some piece of information without reference to a memory aid. The more you try to retrieve something without a memory aid the better it gets lodged into your long term memory. And when things get embedded in your long term memory you start to see more patterns–that is, roughly speaking, the better your long term memory of things the more likely you are to be able to cope with novel situations. I cannot recall the technical discussions I’ve seen on this but as you learn a subject more deeply you develop something akin to an intuition about how things should work.

Dr. Hermans’ mention of retrieval practice finally helped me to articulate something that had been a half-formed thought in my mind for a while. Intellisense and similar technologies–while they are a boon for experienced developers–very likely hinder the learning of novices.

This is why I’m starting to consider intellisense harmful–at least for novices trying to learn coding. Because they’re never forced to try to retrieve syntax from memory it doesn’t stick as easily in their long term memory as it did in the days before intellisense. When you’ve got the immediate feedback that you’ve typed syntax wrong and you can monkey around with your code until the red squigglies go away, then you’re never forced to recall syntax. Or least you can delay committing syntax to long term memory much longer.

I think we need to seriously reconsider starting novices with Eclipse and Visual Studio. I think rather than helping us to turn out more developers I think this is mainly creating novices that will stay at the novice level much longer than they need to.

I cannot be sure–I don’t know if there’s any formal diagnostic that a mental health professional can perform to diagnose impostor syndrome (assuming it’s even a recognized mental health concern). So I won’t say that I suffer from impostor syndrome but it’d be hard for me to imagine that I have never felt the effects of it at any point in my life.

I was doing training for the last couple of years. The VP of the Training Team–a phenomenal trainer and a pretty good judge of people–said to me that one thing I could do better as a trainer is to be learner focused. That is, to do more to put myself in the learner’s place and thus figure out how to make it easier for them to learn what I was trying to teach. And he’s quite correct–I do have a hard time understanding things from the perspective of someone else.

This Can’t Be That Hard!?!

One of the causes of impostor syndrome as I understand it is the feeling “it’s just not that hard”. I mean I can recall taking differential calculus and thanks to some excellent instructors it all made sense and it wasn’t that hard to understand. I can recall taking integral calculus and that, likewise, didn’t seem that difficult to understand till we got to a point where they told us to start memorizing tricks to solve certain integrals. That’s where they lost me. But again, due to great instructors, the preliminaries–the idea of a series of polygons under a curve and the sums of the areas of those polygons–well it just seemed obvious.

I’m not saying that it’s not tough. I’m not saying that I’m that smart. What I am saying is that when the material seems obvious in some sense of that word, it’s really tough to understand why it isn’t obvious to everyone. Well, of course, as the width of the polygons under the curve approaches zero the approximation of the area under the curve will become more accurate. Well, duh!

To me this is the other side of impostor syndrome. That inability to understand how the material could be difficult for anyone to learn or master. That feeling of, well, of course thus and so is true–this can’t be that hard, right?!

I’ve had people tell me that they think I’m a good trainer. I have my doubts. Considering that I would ask people about things I’d demonstrated to them just a few weeks before and they’d look at me like I’d grown a third eye, I think I was not a good trainer. I guess time will be the ultimate judge of that. But not being able to empathize with people you’re training because the material just doesn’t seem that difficult to understand doesn’t help the matter.

I’d like to flatter myself and think that I was good at explaining things to my learners. But the truth of the matter is that no matter how I approached the materials I was trying to teach (software development and some very basic CS) it’s tough material to master. If it seems obvious to me that’s because I’ve had years of doing it to make mistakes and internalize the explanations for things.

Last year I had several friends inquire if I was going to stage another DetroitDevDay. I had taken over from my dear friend Dave McKinnon and I had run it for a couple of go-rounds. Honestly though, I was getting a bit worried that DetroitDevDay was becoming almost YADLTC (Yet Another Day Long Tech Conference). It’s wonderful to see the explosion of tech focused events here in Detroit and I am truly gratified to see so much going on here but where did DetroitDevDay fit in that picture? That was the question I was struggling to answer.

There are good .Net oriented conferences now. There are good Java oriented events (although truth be told they’re mostly Android/Google events). What could DetroitDevDay do to contribute something different–something worthwhile?

Then I hit on it; I want to talk about what’s coming next and I want to talk about it with other developers who want to look at what’s coming up to see if there’s value in it. And that’s where Detroit Tech Watch was born.

So why not just stick with C# or Java?

I think a lot of developers are in the position of doing C# or Java because it pays the bills. That’s not a knock on either technology stack; it’s simply become somewhat de rigeur to pick one stack or the other and then use it for everything. But we all know that there was a time before OO and C++ and its progeny. And there will be a time afterward as well. COBOL was once cutting edge–now it’s legacy.

Another interesting development (and to be quite frank a bit concerning) is the rise of coding bootcamps and “You too can be a developer!” While this is absolutely terrific in terms of giving people an opportunity to better their lives, in terms of wages it’s going to drive the wages of C# and Java developers down. That’s not a noble or unselfish reason to look at stuff beyond C# and Java but it is a fact.

At some point if we don’t pick up our heads and look for what’s coming next we risk becoming the software developer analog of KMart, Sears, Circuit City, Newsweek Magazine etc. etc.–that is, disrupted right out of business. The trick is not to see what’s coming next. The trick is to spot what’s upcoming that has real value and get on it. And that’s tough.

So we (Mike Onslow who is really a heck of a smart guy and I) are going to try DetroitTechWatch 1.0. Even though it is 1.0 it’s really sort of DetroitDevDay 8.0 with a different emphasis. We really hope that if you’re interested in hearing about what’s coming next you’ll join us. Or you’ll submit a talk. Or both!

We (the folks who previously put on the DetroitDevDay conference) are going to be starting a new annual event on June 29, 2019 at TechTown in Detroit. I will share more details here as I get them but I wanted to make sure folks are aware.

I’ve been having a conversation with some folks on Twitter about their evidence that mob programming makes Brooks’ Law irrelevant. Someone offered evidence based upon his own experience that mob programming breaks this rule.  I hope I’m not mischaracterizing his argument. That is,  I don’t think he’s saying that mob programming negates Brooks’ Law–I think he’s saying that multiple programmers can work faster via mob programming.

I had pointed out that while his experience is certainly evidence it’s anecdotal evidence.  This is not to belittle the importance of anecdotal evidence. It is to make a distinction between experimental evidence and anecdotal.  I’ll relate an example that I hope will help to clarify my thinking on this point.

I’ve raised domesticated pigeons for a good portion of my life.  I know lots of folks who race their pigeons (I do not).  I was told that one of the old sachems of pigeon breeding, a gentleman named Joe Quinn, was trying to convince breeders to vaccinate their birds.  He was having a hard time convincing the racers to vaccinate their birds and as a result, flocks were getting hit with easily preventable diseases.  So he hit upon an idea.  He convinced one of the better breeders to let him (Joe) vaccinate his flock at no charge.  The breeder didn’t mind since it was free.  At the end of the season the other fanciers asked the master breeder what was his secret of winning races.  The master breeder said that he did pretty much what everyone else did (that is, training, selective breeding etc.) but he did get his flock vaccinated.  The next season all of the fanciers wanted to get their flock vaccinated.

This is what I mean by anecdotal evidence. Did the vaccinations make a difference?  Of course they did–they protected the birds against preventable diseases. But did the vaccinations make a difference in the races?  That’s more debatable.

Experimental evidence would be vaccinating half of the flock and leaving the other half unvaccinated and then comparing how the birds raced at the end of the season.  Of course everything else would need to be held equal–equal diet, equal training, equal housing etc.  The result would be experimental evidence that the vaccination either made the birds race faster or not.

As it stands however, saying vaccinating the flock made the birds race faster is anecdotal evidence.  Heck we might even be able to prove it had no effect by looking at the race times pre-vaccination and post-vaccination–although there are likely to be other complicating factors present.

The thing is it’s really hard to do a double-blind study this way when it comes to software development because there are just too many other factors to try to hold equal.  If one team uses mob programming and they’re more productive–well was it the mob programming that made them more productive or was it that they had an easier task to accomplish or was it the fact that the team had long experience together or so forth and so on.

So we’re mostly stuck with anecdotal evidence when it comes to software development because producing experimental evidence is so difficult.  As I said on Twitter I’m not doubting the anecdotal evidence–I’m just doubting that mob programming is the sole difference.  The fact, all by itself,  that a team is willing to try mob programming probably indicates a team more receptive to trying new ideas and hence possibly more productive for that reason alone.  I’m not doubting that mob programming is beneficial; while I don’t have experimental evidence to prove it, I also believe it’s a good idea.