Numbers are not just symbols on a page

The above was the title of a project we had to work on this week. We have had a few projects in C before, but all of the previous projects were mainly an introduction to the language. This new project was very different. See, Holberton School’s goal is to shape us in to ‘full stack’ engineers.

mmmm… but that term is a little vague, and is used loosely in this industry. In fact when I was thinking about heading west to attend Holberton School, I was weary of the term. Before coming out to San Francisco, I was planning on attending Mobile Makers in Chicago, a boot camp for iOS. Don Bora, co-founder and chief instructor of Mobile Makers, and a friend of my father, was excited when he heard I was going to attend Holberton, but was weary of how the school train up ‘full stack’ engineers. Full stack is a very broad term, and it morphs into a lot of different things deepening on how people want to use it. You might run into people who call themselves ‘full stack’ engineers because they can do both front-end and back-end. Cool, great… glad you can do two things…. but ‘full stack’ at it’s core means something very different. Look at it this way – lets take for example a a webpage to purchase a flight to California (this being an open invitation for my Chicago friends to come visit…hint…hint). You have the front-end, the part of the webpage that you are interacting with, where you put in your personal information and your select a destination of California. The back-end deals with servers, an application and a database, so that when you log back into that webpage, you can check your flight status and see that unfortunately it is delayed because of bad wether in Chicago (more reason to visit California).  So there you have it- front-end and back-end… but wait… there is so much more to software engineering then just that. What about all the other parts like security, and the construction of the very languages that everything is written in?  I haven’t even mentioned the soft skills like marketing , or other behind the scene things like system administration. There are so many layers when it comes to software engineering. With a humble and realistic understanding that nobody can be and expert in all areas of the full stack, Holberton’s goal is to make us all at lest proficient enough to peel away each layer and deal with bugs no matter how deep down they go. To be able to do that, you do not need to master every aspect of software engineering, you just need to have a solid understanding of how each part fits together and have the tools in your tool box to figure it out from there. And that is why we are solving algorithms in C.

SO back to the top of this post. Our task was to ‘Write a function that takes an integer in parameter and prints it’. Sounds easy right. Just write a function that takes ‘n’ number and prints it on the screen. HA. NOPE. Not easy at all. This was a restriction among many others.

  • You are not allowed to use the standard library. Any use of functions like printf, puts, etc… is totally forbidden.

WOOF. The only function we could use was ‘print_char’, which prints a single character. Not super helpful when a six long digit is passed into the parameter. We needed to figure out an algorithm that would take a given number, figure out how many digits were in that number, from that extract each individual integer that makes up that number and print them in order. Figuring out the algorithm was daunting. After the task was posted, a bunch of us were still stumped… so we shoved ourselves into the only meeting room with a white board to hash out the problem. A few hours later, we had a semblance of an algorithm, with no code attached. Some of us felt like, “oh, great… we haven’t gotten anywhere”. But Julien, one of our co-founders, wanted to make a point with that. He said, the hardest part of this task was figuring out the algorithm, the code part is easy (well, maybe once I am better at C it will be the easy part). He wanted us to realize that when we are faced with a problem like this, you can not start with the code – you have to first figure out how to solve it with pen and paper. Let me make myself clear, pen and paper will never be antiquated. It’s a hard lesson to learn when you have been spending upwards of twelve hours a day typing way on a computer.

Algorithms are not going away. We are learning to use our brains and the tools at hand to solve problems. And that is exactly what a ‘full stack engineer’ should be able to do with confidence an ease. I’m not there yet, but conquering algorithms and C are a few of the tools in that tool box.

One comment

  1. Tom Bredemeier (@TomBredemeier) · February 11, 2016

    Well said. I think of Stephen Covey’s quote “All things great are created twice, first in the mind of its creator, and then in reality.” The first creation is the hard part, but the second creation can also be really frustrating, like when you finally know what you want to do, but don’t know how to go about doing it. You get better and better at the second part as you become familiar with the tools (e.g. programming language). Then it becomes pure joy when the first creation comes together, and code just flows out of your fingertips. Here’s to your future ‘flow’ moments! Hang in there; they will come.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s