The story of little printf

[Foster]

This is a fairly long article about a 10 minute read. But I found it interesting because it's a very good overview of the programming microcosm.

http://ferd.ca/the-little-printf.html

I could identify with the Software Architect, when I did that I also had drawings all over my windows. But, when I designed something, I always felt that I could program it. I got a rep with programming teams to come with tricky bits of code and I could make it work. Lots of times all I needed to do was write the first few hundred lines and then the team would take it over.

I also identified with the tools person trying to pick the next "full stack". Any more with all the frameworks and the plethora of data base / big data interfaces it's a real mess to figure out the way forward. I also got a laugh since I'm pretty fluent in Cobol and once programmed in Mumps (and the wacky data store that goes with it).

[DonRotolo]

We are nerds, aren't we?

I can program, but I am not a programmer. I am a writer, a writer of explanations. But in that story I see myself, and some of my colleagues.

Keeping me grounded in the human face is why I mentor FRC, and why I don't dare stop.

Good read - longer than 10 minutes, but worthwhile.

[GeeTwo]

I agree with Don - way longer than 10 minutes, but I can verify that I have met every single character whom lpf encounters in the story, though it was over the course of many years, and in most cases I had outgrown being so outspoken and held my head-shaking until I was out of their office.

The bottom line is that life is a constant conflict between what you'd like to be doing and what you can make enough money to keep going by doing. Don't make all of your decisions the same way - one leads to the poor house, the other to misery. Find the balance that works for you.

[Greg McKaskle]

The story also highlights the importance of peer review.

I have also known characters like printf met on his journey ... past tense. The peer review will either help them past their local minima, or it will help the business/entity as a whole.

Perhaps printf will go into project management.

Greg McKaskle

[marshall]

This was good (if not a little depressing). Thanks for posting it!

I feel that at different times, my career has been or has crossed paths with the archetypes from the story. Sometimes I have handled it gracefully and sometimes... sometimes I have to remind myself that I am doing work to help people who aren't programmers or IT savvy. Mentors are people too as it turns out.

This is a good story. I feel like there are a lot of corollaries to other fields outside of programming too.

[wireties]

Yikes - now I will endeavor not to fall into the caricatures that little printf encountered!

Advice for little printf... be an engineer and solve problems. This is goal number one. Software design techniques and computer languages can be your tools of choice - or not.

[Doug Frisk]

Well I'm offended, no one gets "stuck" writing MUMPS, it's a rare privilege! :D

[MrRoboSteve]

I also recognize every single character in that story.

I've found that it's a battle to avoid falling into one of those stereotypes. Despite having had the "architect" title for several years, I routinely commit code to our service (most recently yesterday afternoon), participate in code reviews, and take my turn in the on-call rotation. All of those things keep you grounded in what is really going on.

Notes on each role:

Chap 4 -- sr engineer -- stops getting promoted because lack of influence over others
Chap 5 -- poseur -- eventually fired from competent places
Chap 6 -- the real engineer
Chap 7 -- framework fad lover - only thing missing here is him having his own framework
Chap 8 -- devops -- managers love these people because they don't complain
Chap 9 -- architect -- this one seems quite disconnected
Chap 10 -- Ghosts of Christmas

[Foster]

Chap 6 -- the real engineer

Chap 9 -- architect -- this one seems quite disconnected


I'm thinking Chapter 6 was more of a sysop/BOFH type person. Most of the ones I've met had a low opinion of programmers, since they were always cleaning disasters. They also worry about everything working. All of the "software engineers" I've met in the operations area are building super complex systems to tell you that something has failed.

There was a little nugget in that chapter about a single program being run on a laptop is critical to the company running. I ran into that a few years ago when I was working on doing a production audit. There was one finance user that had their laptop died or gotten stolen the company would have come to a halt for more than a few days. He was not happy when we took his laptop to make backups of the system and then move it to a server.

Chapter 9 was disconnected, but then I know lots of "white board system/enterprise architects" They have stuff that looks good on the wall, but not really that good in the world. They are often disconnected from the real world company activities.

Nice to see you as an architect updating code.

[Foster]

For those of you wondering, the Little Printf is a take off of the book (and soon to be movie) "The Little Prince"

Wikipedia entry for the Little Prince (https://en.m.wikipedia.org/wiki/The_Little_Prince) and to be complete the IMDB entry (http://www.imdb.com/title/tt1754656/)

It's the same plot line, a little boy meets lots of people and asks questions about what they do.

The Little Prince book is ~60 pages, so it's a solid 30 minute read. There is even a "Cliff Notes" version out, since lots of schools use this text in class.

For the Canadian readers, the copyright on the book has expired. You can get a PDF copy here (http://download.bioon.com.cn/upload/201111/21084046_8501.pdf). The book is still has an active copyright in the USA and France (expires 2035), so you'll need to get the book from Amazon or the Library if you live in one of those two locations. (For most other countries that are FRC members, the copyright has most likely expired in your country. Your country specific Google is your friend.

Maybe reading the two pieces will ignite some of our more prolific authors and artists to write "The Little Roboteer". I can see chapters about mechanical, electrical, programming, tactics, drivers, CAD engineers, fund raisers, out reach leaders, mentors, team support (food, logistics), event volunteers, etc. All of which have a different view on what robotics is.

Draw me a sheep.