Hacker News new | past | comments | ask | show | jobs | submit login
The Little Printf (ferd.ca)
529 points by gmcabrita on Oct 12, 2015 | hide | past | web | favorite | 84 comments

Wow. I'm a college student, but I still feel like a kid. This seems to pretty much sum up every reason I decided not to study computer science and make a career as a developer. I love computing, but I have just gotten tired of the billions of js frameworks and wars about how everything anyone tries to do is wrong. Little printf strikes too close to home. This is a fantastic piece of writing.

> the billions of js frameworks and wars about how everything anyone tries to do is wrong


This isn't universal. HN is one of the places where it is the worst. I probably wouldn't be fighting with Go right now if it weren't for HN; I'd probably be using Java. Staying up to date isn't really as important as it appears. There are people having successful careers with COBOL right now, and while that may not be where you want to go, switching between JS frameworks does not sound any better. And you can basically ignore the JS frameworks. They don't matter.

Because of HN I switched from TextMate to Sublime Text to Emacs to Vim. What did I get out of it? Not a thing. Maybe I can type a little faster when I am in vim. But mostly I just get annoyed when the rest of the OS doesn't support the shortcuts that I am now used to. I switched from Mac to Linux to Mac. I got nothing out of it, except that now I get more annoyed when I can't do something on my Mac that I was able to do on Linux. Don't do what I did.

I think it's completely possible to be a developer without all this, as long as you can recognize when you are wasting your time.

One of the most cheerful people I met was a guy on the commuter train about ten years ago poring over a greenbar fanfold[1] listing of COBOL code used in a gas station point-of-sale backend. I asked him about it, and he enthusiastically told me about what he was working on and how a problem had developed over night that he was going in to work on. It made me realize that software development doesn't have to be bleeding-edge to be interesting. Indeed, I thought the stability of an established COBOL ecosystem might be refreshing.

1: https://en.wikipedia.org/wiki/Continuous_stationery

> Don't do what I did.

I try. I don't think going from a GUI editor to Emacs was a complete waste of my time and I still like it a lot BUT whenever you make that kind of switch you gotta stay out of the "this is the best thing ever" mentality. Instead of seeing $EDITOR as the Holy Grail that cannot be eclipsed by anything (which is false) I see it as my favorite tool in a toolbox. I like it but I also recognize it's just one of many tools and it's not always the one I should use and getting frustrated at the differences is pointless.

That last bit took a while for me to realize. I think what helped was seeing other people code without my favorite editor with an IDE or something. Watching Notch coding an FPS using an IDE caused quite a few of us in the HN thread that followed to just kinda take a step back.

I'm still relatively new to programming so hey thanks for the advice.

I started using Emacs 20 years ago and have happily stuck with it.

What separates good programmers from great programmers is that the latter know what not to learn.

If you look at most of the great computer scientists and system architects, they all have very unconventional and personalized setups which are completely far off the grain.

I think you're painting too bleak a picture. A balance is needed between chasing the shiny and ignoring the world's movements.

Whether you're a developer, a medical practitioner, a lawyer, an accountant, in real estate, a mechanic, a civil engineer, a teacher, a politician, whatever you have... to be a good professional, you need to keep up-to-date. This doesn't mean latching onto the bleeding edge, but it does mean learning things and occasionally trying new tools or methods.

"Don't do what I did"

Unfortunately, you're a few years too late... I switched from TextWrangler to vim to TextMate to atom to emacs to vim. Totally pointless and stupid (of me) in retrospect. Same thing again with web. I'm finally learning to ignore the shiny but it seems like everyone I see/meet (both online and in person) are only interested in the backwards-incompatible new release of Express 17.0 for NodeJS, now with ES7 features.

Thanks for your response. Looking back and moving forward, I guess.

Emacs to vim boggles my mind. I mean, I've been a vim die-hard for decades now, but I'm not sure there's a compelling reason to switch from emacs to vim or vice-versa. To my mind they are pretty much equivalent feature wise.

I was considering this actually, but opted for eventually learning evil-mode at some point instead. Vim has superior approach to keybindings, but Emacs has the power of Lisp. Evil-mode feels like best of both worlds to me.

I've mostly switched from Vim to Emacs by using spacemacs: https://github.com/syl20bnr/spacemacs/blob/master/doc/DOCUME...

I like the keybinding conventions (all starting with SPC, hence the name).

Spacamacs is definitely the sweet spot.

When I switched from emacs to vim, I was looking for something that

1. starts up fast - I used emacsclient but that got to be sort of a headache, and still did not start up as instantly as Vim does

2. Better keybindings - I would have used evil-mode but I felt at the time that it would be better to use actual vim.

3. Runs in a terminal window - Absolute necessity, so my only real choices were emacs and vim. I liked the workflow I had with `emacs *.py` or whatever I was doing but I thought at the time that vim would better support it.

A friend actually pushed me into using vim, which is funny because he uses the arrow keys with it... I got used to vim way quicker than I expected to, mostly because it was the only editor I installed at all (I switched from emacs to vim at the same time I switched from mac to linux)

Of course i do not recommend you switch between them but those were my reasons at the time.

The Emacs key combinations overlap with the standard Windows shortcuts in ways that make it hard (for me) to switch back and forth between Emacs and Office. Vi key combinations seem to occupy a completely different part of my brain.

I should note that each phase was pretty short lived, as in I barely scratched the surface of emacs.

You can ignore all that and still make a career as a developer.

I started out as a physics major, largely because I didn't want to lock myself into a practical career at the beginning of college. Spent most of my college career avoiding my physics homework by learning lambda calculus, and Haskell, and compiler design, and all of the impractical side of computing. When it came to get a job, I dusted off my Java and got a job in a financial software startup. Left it after two years after discovering that I hated finance but actually liked both software and startups. I've made more tech switches than I can count since, but it's always "Well, what do I need to know to get a job that will pay me and give me interesting challenges?" rather than "What do I need to know?"

You can choose to avoid all the language/framework/editor wars about which is better. None of them are better; it's just some are better for certain circumstances.

The first part of your experience sounds very similar :). Thanks for sharing it.

The real value of an engineer is 10 or 20 percent in what frameworks they know, but 80 or 90 percent in what they can learn. That's especially true in today's embarrassment of riches world in which no one could possibly learn everything.

It's really a great time to be in software, despite the problems. The world runs on software and this will only be more true in the future.

You don't have to hit one of the pitfalls in the story. After all, printf himself ended up as a happy programmer with a human face. If you love programming and you can stay focused on doing what you love, then no matter what else happens, you win. And if you don't enjoy what you're doing, then you lose, no matter what kind of paycheck you take home.

Exactly. Some of the best folks I've hired or worked with had no experience with the framework/language we ended up using. Knowing fundamentals is far more important.

This is also why managers that pick languages based on "hireability" are wrong for the most part. In any non trivial system, learning the domain and existing codebase will dominate the time to learn a new language. It's a nice bonus to have experience with a certain piece of tech, and for baby apps that might be the most important thing. But not for real systems.

> Some of the best folks I've hired or worked with had no experience with the framework/language we ended up using. Knowing fundamentals is far more important.

This is what we want to be true.

It's not how 90+% of job listings are written, and I'm not sure it's how we hire.

Even if we addressed that problem, it'd still only be true at a close approximation: once a framework/lib/language becomes leaky enough, or has enough of a mismatch between its natural invocation and the problem domain, or carries enough of a culture of The Right Way To Do Itâ„¢, then it's true that experience with the tool matters... as long as the org is more invested in the tool than a solution that doesn't have those problems, knowing the tool's foibles and practices remains important.

Companies have a wide variety of hiring practices. By making yourself bad at one hiring procedure but good at another, you'll select for the companies that are selecting for developers like you.

Getting a job is not a numbers game unless you just want any old job and really hate jobsearching. I've found that making myself unappealing to the organizations that I wouldn't actually want to work for has paid off significantly in both financial and job satisfaction terms.

> This is also why managers that pick languages based on "hireability" are wrong for the most part.

This is 80% of what's out there though, FWIW.

Software development is all about solving problems and developers think they are good at it ... so much so that we try to problem solve the solutions (recursive framework hell). I think what this parable is trying to illustrate is that developers ought to focus on problems "with a human face," ones that don't revolve around solving problems that are caused by software development.

JS has a very particular ecosystem and it certainly doesn't describe every other ecosystem in existence today. Basically what I'm saying is if you love solving human problems, software development is an intellectually stimulating and satisfying fields to get into.

I think the Javascript framework of the month fad is a complete waste of time.

Quote of a friend of mine: we developers keep solving problems we would not have without developers.

I really like this quote, because I believe that it's nearly impossible to stay motivated fixing stuff over and over again in similar ways, year after year.

At some point you need to realize, that the systems we created can not give you complete fulfillment. There's always something better, faster, nicer. "The grass is greener over there" kind of thing.

I found my peace by being part of a family with 2 kids, doing fun game projects after hour when everyone's asleep and getting into drawing and music. Programming can be fun, but it's not the end of it all.

> we developers keep solving problems we would not have without developers

I genuinely don't understand. Do you not consider the organizational problems of society to be worth solving?

There was a time, when not every household had a computer. A time where kids were playing without stuff supported or made by computers. Not everything was better back then, but the world did not collapse due to unoptimized processes. In contrary, I believe that alot of things were more 'personal' in the past, but this is highly subjective.

Technology made alot of stuff possible which would not be possible without technology. But the tradeof is, that we must live with systems which increase in complexity each year we use them. And there's no end in sight.

We developers in some way are trying to get out of the hole we dug ourselves into. Think about this the next time a framework comes along which solves all problems of the previous one. At some point you'd wish back the former days, when everything was simpler...

From my perspective - there was a time, when not every household had a computer. I lived in that time. And compared to today, I'd absolutely hate it to get back.

But I also hate how the world is different from what it could be if we as a whole cared about actually solving real problems instead of making money. The world could be optimized more. It's not. We've created lots of cruft and triviality. Even our tools of social interaction are designed to be barely working, the minimum amount of value that will still make people use it so that they can be monetized.

We've created really powerful technologies. And we're using them to like 5% of their capabilities for actually making the world better.

As I interpreted it, the "problems we would not have without developers" isn't referring to the people, it's referring to the tools and processes of development. Especially the tools; don't let "the tools themselves [become] a problem".

Gotta say, people who consider that the "organizational problems of society" can be solved have been responsible for a lot of misery over the centuries.

Nice characterizations but the conclusion was only empty "human face" platitudes for me. I'll take the reminder that we should believe in the end result we're accomplishing and not only obsess about making the tools we're working with or system we're working on better as an end in itself.

And it also doesn't seem to recognize that for some (many?) that tech can be an end by itself. If your goal is business or to ship an app, this might not be true. But there should be no shame, no regret, in only being interested in tech for its intrinsic merits, independent of "results".

Hell, this is the reason a lot of programmers begin programming. Personally, this is the reason I started programming and sadly 90% of jobs that are in the industry feel like utter bullshit to me - I simply can't be passionate about that new sports webapp (I hate sports) or inventory management something something. Especially webdev, of which I did most commercially, feels utterly awful to me. Of course those projects are important to someone, they may be passions of many people - just not of me personally. This creates a lot of tension and unease for me as an employee, especially now that us geek programmers are outnumbered by 'professionals', who came here to do jobs for money.

I own you a beer. :)

Sometimes a story is not the conclusion, but the journey taken to reach the conclusion. :)

Fantastic little parable. Saw a part of myself in quite a few of those.

One I'd like to add is the developer who's so enmeshed in maintaining FOSS software that all they can do is label & triage tickets but never quite find time to start fixing them. I've found myself caught in that lately and am trying to figure out how to chip away at the ever-growing Issue Monster I've let form.

This is where a junior developer can really help, even if it's junior in the sense that they are not as familiar with the project as you are. There is no better way to become familiar with the true problems and priorities of a project than to triage bug reports from the people actually using the software. You may be too deep into it to see that.

Don't prioritize based on what is the "fun technical challenge" but instead figure out how you can get users to be happier with what you are building. Also remember that sometimes the answer is code, and quite often it is documentation or a code sample showing the "right" way to do it.

Strangely, what you are doing may be closer to helping humans than the caricatures from the story. The tickets presumably represent real problems experienced by real humans, and maybe the labeling and triaging brings them closer to actually being addressed.

What project(s) are you referring to? I presume the tracker is publicly visible...?

I would say the observations that little printf brings up have happened to me in various points of my life.

And those nasty habits (ie trying lots of new crap.. complaining about existing crap) typically surface when I don't have a real problem to solve.

And that is the problem... my business is doing well but I just don't have any serious problems that are interesting to solve other than sales/marketing. I'm just not creative enough to find/create a problem worthy to solve that are not completely a mismatch to my current predicament (like I could leave my discipline and maybe do something else but I have obligations).

I really wish I had more creativity.

You don't need creativity you just need to find a problem to solve.


Some of these characters are hitting a little too close to home.

What a great read.

Did anybody read this and just feel sort of sad?

Isn't it the same with little prince? I remember how sad I was when I read that as a kid. Now I'm adult programmer and felt sad as well when I read this.

The Dunning Kruger one was so on point, this is amazing.

parallels with 'The Little Prince':

draw me a system ~ draw me a sheep

proud senior engineer ~ the king

rails -> nodejs -> meteor guy ~ the accountant counting stars

anyone have more?

"..based out of the Little Prince, because as in true software fashion, nothing is truly original.."


If you don't pronounce "printf" as "print-F" but closer to /'print(h)f/ it kinda sounds like someone saying "prince" with a lisp (or with a local anaesthetic impairing the range of movement of their tongue).

I think Northern European languages like Dutch, Swedish or maybe even Polish might have a word which could better describe the sound? I can't think of any Croatian words that get close to it.

Additionally, the little printf their self looks eerily similar to The Little Prince.

"The essential is invisible to the computer" ~ "The essential is invisible to the eyes"

This is a good story. After being a developer for 22 years, I got involved in education, and now I'm blessed to be in a great job at a great school. I still think software development is a good career with a lot of advantages over the alternatives, but I think this story is correct in that you should make sure to serve other people with your work rather than only your own interests and self-advancement.

I had the great pleasure of seeing this read in person. It was brilliant.

Seconded. http://chicago.citycode.io/ was the best conf I've been to and I hope there's plenty more.

Pick your tool and go build things with it. Don't get stuck in the hardware store quibbling over what kind of hammer you need. If the things you build turn out to have been good ideas then when you need to go back to the hardware store to find a hammer that is a better fit you might actually know something about which one you need.

This reminds me of reading _why's stuff back in the day. Bravo.

This just makes me a bit sad. The woman stuck in a job she hates fighting fires constantly... And the most the parable can offer is "sucks that you're unlucky"?

The best we can hope for, if we want to develop software for a living, is to live within our delusions and hope we're never unlucky then?

I would say it's a cautionary tale against making it so people get used to you accomplishing small miracles, or making sure everyone is aware you wouldn't tolerate only doing the tasks you hate forever.

Just one word "Mind Blowing". Complicated feelings of programmers and why we do what we do is explained in simple words.

Why I'm leaving software engineering... :(

This is beautiful.

Hmm! I don't get it.

The Little Prince, by Antione de Saint Exupery is a classic tale and this is a rework of it.

It's an apathetic exposé/critique of various roles in, approaches to and/or views of software development. "In the end though, it is only when you solve problems with a human face that you can feel truly right; What is essential is invisible to the computer."

I see. Personally I prefer to just be a developer, not worry about how other people are doing it wrong... though like anyone I have plenty of opinions on such matters.

I think the software architect role is outdated by now?

I've yet to meet even a CTO that doesn't get his hands dirty with code from time to time.

Not in government and large corporations.

The little printf interjected: No, that's not what I mean, and he then added I mean it's funny that tools are meant to solve problems for us, but for you, the tools themselves have become a problem.

HN homework should be to re-read that section a couple of times.

"The chief cause of problems is solutions." - Eric Sevareid

Loved the story :) it was nice to learn that ferd has studied in the same program as I did! I could relate a lot.

The feels. 10/10 will read again.

On a side note, love the font

The link times out but based on the title, I like what they are saying.

There's a PDF version on S3, if that helps: https://s3.amazonaws.com/ferd-ca/printf.pdf

What a wonderful story. Thank you for lightening up my day.

Regarding the printf (pre)history see my old comment:


printf is based on the idea implemented as early as 1956, next year it will be 60 years since!

   1956: Fortran I:
            PRINT 1, X
         1  FORMAT (F10.2)
Fortran was invented by John Backus and there was already a finished compiler in 1956.

I/O in the first Fortran, I believe including the FN.M syntax, was implemented by Roy Nutt, also one obvious genius:


"There were a few pages of description of a new assembler format for the IBM 704 that differed considerably from the NYAP that we were using." (That) "704 assembler, originally called SAP, was written in its own language by Roy Nutt."

That's very interesting, but other than in name not related to the article.

If you didn't read it I would recommend you do - it's possibly one of the most interesting and reflective things I've ever read about programming as a profession.

Consider it an addition to the type of the programmer: the one who stays by the original meanings of the names. Who still links to the Fortran libraries, writes mostly C and fondly remembers APL.

Shame that we're just nearing precompiled xprintf statements. It's so wasteful and slow to keep scanning same string for printing instructions at runtime. And very bug prone.

Common Lisp had precompiled printing/formatting for ever: FORMAT. E.g. FORMAT is a macro.

And Idris even enables a type-safe version: https://www.youtube.com/watch?v=fVBck2Zngjo

So if you mismatch the types you'll get a compile time error instead of a run time error.

That's pretty cool. Looking for the text version of it led me to another one more accessible to average programmer:


F# also supports a typesafe printf format notation.


To be clear, FORMAT is a function possibly with an associated compiler macro to expand constant format strings into more efficient code inline.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact