The Five Stages of #undef rad1

This was sitting in my "drafts" folder from many moons ago. Looking back on it it's entertaining, so I'll post it now.

If you've had to deal with Windows in C++ land, you are probably aware of some of the many "fun" #defines that Microsoft is guilty of, such as near and far. Or, similarly frustrating for anyone programming trigonometric functions, rad1 and rad2. In the case of the latter, they sometimes manifest in the form of:

Error 1 error C2143: syntax error : missing ')' before 'constant' c:\repos\codebase\lib\headerThatUsesTrig.h

In this "article," I cover the five stages of dealing with Microsoft's rampant #defines, starting from your first completely oblique compiler error, like above.

The World's Worst strcpy, or: How I nailed an interview by getting stumped.

Let's say you got really lucky and landed yourself an interview at a job you really want. You study up for the interview, and prepare in every way you know how. You've studied the algorithms, the syntax, the code, the design patterns, and everything. And you're confident you can ace any little quiz they give you.

Then you come across a question that absolutely stumps you. Something like, maybe:

What is the function of the following block of code?

01 while(*a = *b) ;

What do you do?

In this article I will go through how to demonstrate good engineering habits—which emphasize knowing what you do and don't know, and engaging with information, over recall knowledge.

How to Take Initiative and Keep Up With Deadlines—Professional Advice

New and veteran programmers alike struggle consistently with keeping initiative up, and meeting deadlines—doubly so when you're a new worker and also happen to be in charge of your own deadlines, as I am.

Moving up from simple coding
means learning how to plan the
actual project.

When you are an intern like I currently am, performance and effectiveness are two key factors to impressing those in power, and earning yourself a full time job (or at least a good recommendation in the case of temporary internships). While many employers will forgive a young professional's struggle and occasional stumbles, good performance in these factors reflects positively on you, and will help you develop quickly in the professional world.

Taking this to an extreme, I would go so far as to say that in order to earn yourself a promotion, these factors are just as important—and may even be more important—than how good you are at the work you do. Consider that architects don't need to be as good at pouring cement or making rivets as construction workers.

In this blog post, I share some strategies I've used to eyeball my workload, set appropriate deadlines, and stick to them. Additionally I'll make an argument for why these skills supersede others when being considered for a promotion.

Internalizing Someone Else's Code: A Real Workplace Skill

I have been programming since I was very young, but would still not call myself a seasoned veteran in the world of computer programming. In fact, I wouldn't even go so far as to say I'm not still a beginner.

Out of the skills they teach you in class, I'm doing pretty well. I'm good at disciplined coding, and ensuring that methods or utilities don't do more than they ought to. I'm good at logically discerning what a class should and should not do, in order to create a more highly-organized class structure. But there are a number of real-life workplace skills that they don't teach you in class: version control, general code management, real planning, and especially coordinating with others.

I've learned many of these on my own, but many are still a constant struggle. Read more about my platitudes in this entry.

A less concrete model of abstraction: PLAM!

I present to you:
the Practical Levels of Abstraction Model

While there are many ways to think about abstraction, many of the accepted models pursue the most concrete definitions possible—something I've always found ironic, given the whole idea of abstraction.

Most existing models for data abstraction describe the disconnect between physical reality and the representation thereof. Which makes perfect sense in the most general way: machine code is less abstract than assembly language, which is less abstract than uncompiled source code; and one could easily compare different programming languages, arguing that Haskell is more abstract than C++, which is more abstract than Fortran, and so forth.

But what about abstraction in the sense of object-oriented programming?

When it comes to writing a program, there is a trade-off for the overall usefulness of code, between two things: how portable you make your solution, and how integrated you make it, with the concrete details of its specific implementation.

In this article, I'll walk you through the Practical Levels of Abstraction Model—PLAM for short. And then I will teach you to use PLAM as a tool for decision making in the software design process.

Don't Ask, Don't Get—Professional advice.

Computer programmers, by nature of their job, need to tend towards being very candid in opinions and factual knowledge, as well as critical and honest when it comes to facts. As a result of the kind of work we do, we typically take written word very literally and very seriously.

But that doesn't always work in the professional world. For example, when it comes to job postings. When it comes to being a professional, there is one lesson that's sat with me always, since my dad first told it to me:

Don't ask, don't get.

Of course, his other favorite quote was from a Rolling Stones song, but let's not go there for now. For now, I'll discuss the lesson, then exposit my recent professional progress, and then discuss how it relates to this very valuable lesson.

See beyond the ideas—Professional advice

The University (with those capital letters) provides a wonderful environment in which students can learn complex concepts, and even receive fantastic training for a professional career. There's a great reason most decent employment opportunities tend require a college degree, and sometimes higher even than that.

But, if you're looking to make yourself a professional,  it's very important to be mindful of the fact that the university's primary functional output is university professors. That is, the most successful university students tend to be those who fixate on abstract problems, rather than the practical application of those abstract problems. Of course, the former is necessary to be a good university professor, and the latter is necessary to be a good professional.

In this article, I go through a few epitomic examples of how The University might leave an aspiring professional feeling, frustrated, erroneously inadequate, and wanting more.