DEV Community: Stan James

The evolution of developer experience in the 20th century

Stan James — Wed, 05 Feb 2020 00:16:49 +0000

A marketing friend once looked at my screen while I was coding and remarked, “That’s so scary looking!” This got me thinking about how we got to this strange-looking multi-colored-words-on-black aesthetic. So here’s a brief history of the developer experience.

Origins

Ada Lovelace is credited with writing the first computer program in 1842. As there were no actual computers, the program never actually got to be run. But it’s fascinating to see how she represented the algorithm on paper, having no precedent to work from.

The program is for the Charles Babbage’s Analytical Engine to compute Bernoulli numbers, which are important in number theory.

Wires and literal bugs (1940s)

The very first computers were built in the 1940’s and were programmed by literally connecting wires, turning dials and flipping switches. “Programming” was a special case of “wiring.” There was no effort to make programming easier for humans. It was enough that these machines could exist at all!

This era also brought us the concept of a program “bug.” The first one being a literal moth that shorted out a relay. Grace Hopper recorded this occurange, along with the moth, in her log book.

Assembly Language (1950s)

The first step toward a human affordance was assembly language, which allowed programmers to use human-sounding commands like “ADD” or “JUMP” instead of remembering numeric codes like “523” or “10011011”. But this was just a thin gloss, so the programmer still had to know the computer’s architecture inside and out.

The code for the Apollo Space Missions is a good example of assembly language, even though it was written in the 1960s. Here is a printout of part of that program, interestingly named kissing!

INTRPVP         STQ     BOFF            # PRECISION UPDATE PASSIVE VEHICLE
                        RTRN            #       TDEC1
                        AVFLAG
                        OTHERV
                CALL
                        CSMPREC
                GOTO
                        RTRN
OTHERV          CALL
                        LEMPREC
                GOTO
                        RTRN

Punch cards and high level languages (1950s)

Languages like Fortran and COBOL used quasi-English function names like “if”, “not”, and “while”, and could be run on different computers as long as there was a suitable compiler.

These first generation “high level” languages were all written in the same way: on punched cards. Each card corresponds to one line of code, usually 80 characters across.

The human-readable code is at the top of the card and reads:

IF MOD-G-JAHR NOT NUMERIC MOVE ZERO TO MOD-G-JAHR.

A program consisted of a deck of cards. Editing a program consisted of punching new cards, or re-ordering the deck.

As shown in the photo below, “comments” would be written on the edge of this deck indicating subroutines. The red angled line was used as a crude method to get the cards back in order if the deck were to be dropped. You can also see old red marks revealing sections that had been re-ordered.

Unlike in modern languages, there was no indentation of lines to represent blocks. Indentation makes no sense in a world where you see only one line at a time! Fortran instead used indentation to distinguish comments (column 1), labels (columns 2-5), and statements (columns 7 and beyond).

C AREA OF A TRIANGLE - HERON'S FORMULA
C INPUT - CARD READER UNIT 5, INTEGER INPUT
C OUTPUT -
C INTEGER VARIABLES START WITH I,J,K,L,M OR N
      READ(5,501) IA,IB,IC
  501 FORMAT(3I5)
      IF(IA.EQ.0 .OR. IB.EQ.0 .OR. IC.EQ.0) STOP 1
      S = (IA + IB + IC) / 2.0
      AREA = SQRT( S * (S - IA) * (S - IB) * (S - IC) )
      WRITE(6,601) IA,IB,IC,AREA
  601 FORMAT(4H A= ,I5,5H  B= ,I5,5H  C= ,I5,8H  AREA= ,F10.2,
     $13H SQUARE UNITS)
      STOP
      END

REPL and line numbers (1960s)

The BASIC computer language was designed to be even easier to use. It was developed in parallel with time-sharing, which allowed many users to interact with a single computer via teletype without needing to punch cards and load them. For the first time, users could now write, edit, and run programs directly in computer memory! This was the first REPL, “read–eval–print loop”.

The standards and protocols developed for this live on as “TTY”, still used in developer terminals to this day.

In the image above, note the innovation of line numbers. Compared to manually sorting punch cards, this must have seemed like a great innovation!

This example from the 1968 manual averages the numbers that are input:

5 LET S = 0
10 MAT INPUT V 
20 LET N = NUM 
30 IF N = 0 THEN 99 
40 FOR I = 1 TO N 
45 LET S = S + V(I) 
50 NEXT I 
60 PRINT S/N 
70 GO TO 5 
99 END

Visual editing (1970s)

The advent of cheap CRTs meant that developers stop wasting paper and write their programs on a screen. Code editors vi and emacs were created, beginning the long developer tradition of arguing over the best editor. (vim, still popular today, is an updated version of vi written in the 1990s.)

New languages like C took advantage of this by introducing indentation. In the image above, the lines after join(int c) are intended, to show that they are within the scope of the function. The lines after the for(a1…) command are likewise further intended. This use of visual space to denote semantic meaning was a real innovation, and a true affordance to the way human vision can spot visual alignment.

This innovation also kicked off the unending “religious wars” of tabs-vs-spaces, 2-4-8 space intending, and “which line gets the brace?”

Syntax highlighting, auto-formatting and visual debugging (1980s)

Mac Pascal was the first editor to check for syntax errors while you were editing, not waiting until you compiled the program.

It also was the first editor to do syntax highlighting and auto-formatting. Because the original Mac could not show colors, highlighting was done with bold and italic.

A few years later, the company behind Mac Pascal gave the world its first visual debugger.

Interface builder, view source, and search (1990s)

After being kicked out of Apple, Steve Job’s founded NeXT computers. The NeXTStep operating system was groundbreaking for developers in that it separated interface development from code-writing. You could now add a button to a window by merely dragging it from a palette, rather than writing lines of code. This program was called Interface Builder, which lives on today in Apple’s XCode, used to create all iOS apps.

The twentieth century ended with the advent of the web. This was set to revolutionize developer experience again.

The web browser democratized developer learning with “View Source”: Anyone curious how a web page was coded could find out in an instant! Suddenly everyone had their own HTML and Javascript development environment, and every new web page was a new example to learn from!

1998 was the twilight of the century, and the year Google was founded. It would become the unsung cornerstone of developer experience up to today, as we copy-paste our error messages and “How do I quit vim?” into its search box. And that’s a topic for another post!

Good code balances efficiency, readability, flexibility, and brevity

Stan James — Mon, 20 Jan 2020 19:33:59 +0000

tl;dr: There are four goals you can prioritize when coding: efficiency, readability, flexibility, and brevity.

In English, we understand that “good writing” means something different between a novel, an airplane repair manual, a poem, and a tweet. But in writing computer code, sometimes we forget that there are similarly different goals that the code may be optimizing for.

In project planning, interviews, and even in personal projects, it’s important to be crystal clear on goals, as compromises are inevitable. Not all code can be efficient, readable, flexible, and brief!

Efficiency

Efficiency has traditionally been the assumed goal of all coding, and remains the primary yardstick for technical interviews. You try to minimize processor cycles, storage space, or network traffic. You analyze with Big O and employ profiling tools to verify. The need for efficiency is driven by the sheer amount of data to be processed (Big Data, training sets, etc) or by limited resources of mobile devices. In extreme cases, this can mean dropping down to assembly code or employing PhD level mathematical tricks.

Resources to be optimized: CPU, memory, network traffic.

Readability

Readability is more and more recognized as a worthy goal, even at the expense of efficiency. For example, what good is it if your nightly batch script runs five seconds faster if only a Super-senior Engineer can understand the code? Or if a single mistake could mean that an eight hour training run gets the wrong parameters passed?

Readability also means choosing names and data structures that minimize possibly confusion. Recursive solutions are often elegant, but experienced engineers agree that generally iterative solutions are easier to understand.

The rise of Open Source has brought readability into the spotlight. A project won’t attract new contributors if they can’t understand the code. Likewise, companies have learned that having a readable code is required if you want to attract people to your libraries. For example, the APIs and example programs for Google’s Tensorflow and Facebook’s GraphQL are clearly written.

Resources to be optimized: future developer time (including yourself!), attractiveness to outside developers

Flexibility

Flexibility is an under-appreciated goal in coding. When building a prototype or merely exploring an idea, one doesn’t care so much about efficiency or helping outsiders understand the code. Instead, one builds for uncertainty. For example, you don’t know yet if the project will use Tensorflow or OpenCV for counting the number of cats that walk by, so you create an interface that returns “numCats” and cleanly allow for different git branches to test out possible solutions.

Resource to be optimized: developer time, switching costs

Flexibility is also the primary goal of explorer-style coding, covered in my previous post Lewis and Clark Style Development.

Brevity

Brevity is the final goal of coding. This is the case when you’re hashing out an algorithm with a co-worker in a Juypyter notebook, or doing a coding interview on a whiteboard. You and your co-worker will implicitly understand that the variable tsr means “total sheep remaining,” or that the first and second elements in each tuple will represent the left and right branches of a binary tree.

In a classic technical whiteboard coding problem brevity becomes important, but the interviewee is presumably also being evaluated on effeciency and readabilty. If you’re being interviewed, it’s best to be very clear what tradeoffs you are making between these.

Resources to be optimized: whiteboard or screen space, handwriting time.

Conclusions

When writing code, one often comes to forks in the road. I’ve found that having clear priorities between efficiency, readability, flexibility, and brevity keep everyone on the same page, especially junior developer who don’t have as much cultural acclimation to intuitively understand different contexts.

Coding styles: Are you Lewis and Clark or building an interstate?

Stan James — Tue, 24 Dec 2019 15:59:50 +0000

tl;dr: Software projects exist on a continuum between the Lewis and Clark expedition, and laying down freeway. Knowing what kind of project you’re on can be the difference between success and failure.

In 1803 Thomas Jefferson commissioned the explorers Lewis and Clark set out to explore the American west, no one knew what they would find. The whole point of the venture was to figure out what was there. Gold? Farmlands? Trading partners? Rivers?

On the other hand, when that stretch of highway near your house was built, the decision to build happened years ago by some planner, the road was built to last for many years, and development proceeded methodically and carefully, drawing upon centuries of road-building experience.

Problems arise when the developers, managers, and product managers aren’t clear on what the mission is; employing the wrong techniques or wrong metrics of success. This shows up acutely between startups and large companies.

Startups are typically explorations. The founders have an inkling that there is value to be found in some direction. The developers write code quickly to explore the space, knowing that almost all of it will get thrown away. You keep scaling and maintainability in mind, but the top priorities are (1) code works (2) that can be easily changed and (3) most importantly, provides some data answering the questions “Is this something anyone wants?” or “Can this be built at all?”

Big companies are more like the highway crew. The sources of value have been located, there is no doubt that the traffic will come once the on-ramp opens. The developers work within a large body of existing code, careful not to break anything. Scalability and maintainability are top-of-mind.

Of course this is over-simplifying: both styles of mission exist within companies of any size. Big companies have innovation and R&D departments, classic Lewis and Clark explorations. And a startup that is preparing to take on their first big customer will want to be damn sure that their code can scale to handle the customer’s use!

But some startups try to act like big companies from the very start, crippling themselves. With no validation that anyone wants the service, they build a system completely containerized, with a CDN, load balancer, de-normalized noSQL scalable database, GraphQL API, and everything written from the ground up in Node. The better solution might be as simple as a Django or WordPress installation with a just a dash of custom code. They’re laying down concrete and guardrails when they should be bushwacking to the top of the nearest hill.

I find that within the developer community there tends to be a fettishization of the “highway building skills.” Who wouldn’t want to believe that their code will need to process billions of transactions? Why wouldn’t you want to use the same techniques as Google or Amazon?

But being a skilled explorer is just as important a skill, but harder to codify. Knowing how to keep your code nimble. Knowing how build that demo that works just good enough that the investors put in money and keep the lights on. Knowing how to find that open-source project that is kinda sorta like your goal but can be hacked into shape.

In short, there is a difference between bad code and exploratory code.

Finally, it’s important to realize every highway owes its existence to some explorer. Facebook began as some monolithic PHP code. Google began as student code from a PhD thesis. Slack began as a whipped-together internal tool of a game company. The beauty of exploring is never knowing what you’ll find!