Hacker News Reader

Comment by markmiro | Hacker News Reader

It would be interesting if programmers took "sketching" to be a valuable and necessary part of programming. It's common practice for painters to make a pencil draft first. It's common in industrial design to produce prototypes.

However, when it comes to code we treat it similar to writing. We may have a first draft, but the final draft is often nothing more than a cleaned-up draft. I could be wrong. I never wrote professionally.

It would be interesting if we had languages that would be great for prototyping but designed to be unusable in production. However, I'm having a hard time imagining properties that don't already exist in languages like Python and JS. You want weak typing of course, but you'd be ok with poor security. Maybe we'd some nice features that would make the language run slowly since it running in prod would be a non-goal.

View on HN

I'm a big fan of literally sketching. One of my favorite things to do when approaching a hard programming problem is to enumerate a list of things I already know and then try to literally piece those together into an algorithm. I typically do this on paper, making diagrams of how things will fit together and examples.

But my "notation" here is always miles away from what code would look like, and I think "sketching" in pseudo-code or real code would fail to provide this same springboard. One of the biggest things with writing code is that data structures (especially in the form of objects) quickly lock you down to a certain design and it becomes progressively harder to think of the problem in any other way than your initial view of it. Plus, the hard parts typically require huge amounts of infrastructure to be in place before you can run them for the first time, which works much worse than an abstract brain model in my experience.

>It would be interesting if we had languages that would be great for prototyping but designed to be unusable in production.

The reality here is that people would find a way to make it usable in production and this vision of a good first draft would quickly fall apart :/

I think that TDD is in a way "sketching" for programmers, you draw the outline (the expected results), and then you fill in and refine the details one by one to make the code work. When dealing with the complex code I also have a habit of structuring the code with comments first: I write a comment for each step in the flow (like a subtitle for that block of code: e.g. parse input, calculate this, get that, output result, etc.), and only when that logic as a whole makes sense I start to implement the actual code below the comments one by one. I find this very helpful to visualize the logic flow.

Part of the reason I like C-style header files for declarations is that I use these as a 'sketch' / 'story map' for the piece of code I'm writing. I tend to spend much more time per line writing my headers than my code, because once I've thought through the public interface and it's close to its final form, the internal code pretty much writes itself.

I notice that I have two modes of programming. This is clearest with haskell.

For simple code I make type errors into runtime errors and let the compiler figure out type signatures. This emulates dynamic languages with a great linter pretty well.

For complex code I write rigid type signatures first and then play type tetris. This works best with dependently typed languages and is called type driven development. Idris can fill in large parts of the program with this - since type signatures are equivalent to propositions and programs to proofs this is basically proof search.

The issue is that in art or industrial design, someone can't reasonably sell the prototype as a completed work. With software, particularly anything that is web-based, as soon as a sales person sees anything that vaguely resembles something they can sell, they will sell it. Sales means bookings/income, so that prototype becomes the MVP.

There is a saying, "real writing is rewriting."

Ideally the final draft is something that has been very aggressively refactored, multiple times, with input from a Refactoring Engineer.

(Did I just invent a new job category? I don't think there's currently any equivalent of an Editor in the Software Engineering world; code review is a chaotic approximation.)

Unfortunately there is usually pressure, and maybe also desire, to just make it work, maybe with tests, and move on to the next thing, at least in companies.

"Build one to throw away"

- the mythical man month

"Can't we just spruce up the working prototype and deploy it to production?"

-- Management

If it only were an actual question...

I've learned in time to never make a working ux in my prototypes. just raw data showing the innards working, and that's it. functional or pretty ux just gets shipped in prod no matter what.

I believe that a Refactoring Engineer would be similar to a contractor specializing in performance, security or systems optimization. I've had the pleasure of working with a couple of these people, and I have to say that I felt an initial (pride|arrogance)-based resistance but they were all friendly and had some really valuable insights especially since their expertise seemed to be lower-level than mine and they were able to look at working code and find places to improve.

In essence I agree with you that this should be an on-staff role, but perhaps the reason we are not seeing this is that the job is usually fairly quick (a couple of weeks/months) and for the business its hard to justify a full-time staff member to perform this service. There is also something to be said for how people in this role are able to gather a wealth of experience by working on a high number of code bases instead of being stuck continuously working on the same few software projects all year.

Don't programmer do this when they create a prototype and reiterate from there until they have a fully functional product? Unlike painting, programming can refactor parts and rearrange everything. There is no need for an additional sketch if the sketch can become the painting.

> Unlike painting, programming can refactor parts and rearrange everything.

You've never seen a "//I don't know why this works, but don't touch it" in code?

I mean, some writers like to make up outlines and stuff to plan out books, though so do stream of consciousness style and clean it up in later drafts. I can see that planning out your code can be beneficial and honestly ideal. Just break it down in a sort of outline what all the program needs and then what each part of the code would need, etc.

Well, I sometimes start by writing psuedo-code first before turning it into actual code, later.

How about all the libraries and tools turn over every two months? Oh, there's JavaScript!

Node.js turns 10 in a few months. TypeScript is 6 years old. Webpack is 6 years old. React is 5 years old. Redux is 3 years old.

Front end JS and TS went through a phase of rapid change 2 to 6 years ago, but I don't think that rapid change is still happening. Certainly there are new libraries, and maintainers still like to play fast and loose with backwards compatibility, but it's not obvious that you have to keep up to date with every single new framework anymore.

Isn't that just domain modeling in UML?

Reply on news.ycombinator.com