7 Life Lessons From A Self-Taught Programmer

I always had a thing with languages. For some reason, I always found it easy to learn them, and had a great time using them. Surprisingly enough, I followed a tech high-school, majoring with a diploma as a programmer in… FORTRAN. After that, I went to the University of Letters in Bucharest, where I studied Romanian and French literature. And in the last 10 years I had my own online publishing company, where I wrote more than 70% of the source code for the underlying software platform.

Why I’m telling you all this? Not to show you that my career life was a roller-coaster, if you read my blog for some time you already know that. But because there’s a link between spoken languages and programming languages. At a certain level, they’re both a vocabulary over a grammar. A programming language can be learned and applied just like learning French or Japanese.

Reality Is Created With Words

If you ever learned a foreign language you remember that special feeling of expansion, both inward and outward. It’s like space is growing around you. And that’s because every time you learn to describe the world in a new language, you actually redefine it, you reinvent it and enjoy it as a completely new reality. L’amour en Francais it’s a completely different thing from love in English, or from dragoste in Romanian. They’re actually new realities. Learning a new language is a beautiful travel.

Now, a programming language is almost the same. It enlarges your mind and gives you access to areas in your life that you didn’t even know they exist. It puts you in uncomfortable situations and forces you to solve complicated problems. Every new app that you start coding is like a trip to Thailand with only a pocket Thai dictionary. When you start the app, you barely know how to say sawasdee, but at the end of it, not only you know how to have a conversation with the locals, but nobody will be able to tell that you have an accent.

7 Life Lessons From A Self-Taught Programmer

I recently finished a very dear project to me, an iPhone / iPad app based on my own life management framework, Assess – Decide – Do. The app is available on the App Store, by the way, and it’s only 3.99. It took me 30 days to put together the first version, but around 90 days in total to have a solid, mature and feature packed app. During this trip, I had an incredible time, learned tremendously and thoroughly enjoyed every breakthrough. What follows is a collection of life lessons learned as a self-taught programmers, mainly while I was coding iAdd.

1. Bugs Are On You

Always. Don’t blame the compiler, the lack of documentation, or the horoscope. You made a mistake somewhere. At some point, something happened in one of your Assess – Decide – Do cycles (yes, you have those cycles even if you’re not aware of them) and you screwed something. I spent countless hours trying to find a flaw in some class or API, basically banging my head against the wall by not accepting that I was the source of that mistake. A typo, a bad copy/paste, or whatever: every bug was in fact my own responsibility.

It’s the same thing in life. If there’s something wrong, check your own history. Don’t blame somebody else. It’s not the universal compiler’s fault (if there would be such a thing like a Universal Compiler, anyway). There’s no glitch in the Matrix. There’s no failure in the Universe. It’s in you. Look in the mirror and try to find out what you did wrong. And then solve it.

2. You Have To Face The Problem, Detours Are Not An Option

Even if you don’t like it, in programming you have to take the most “difficult” path simply because there are no other options. Workarounds are fragile. They may solve the problem for the time being but their fragility will show up the moment you’d want to expand your app. Do it the right way, fix the problem for good. Or, if you settle for workarounds, expect things to blow in your face the moment you’re expecting this the least.

It’s like in life: you can’t live in a continuous status-quo. You gotta take responsibility for your choices, climb the mountain you have to climb, because the solution is always on top of that mountain. You can’t take a detour. Or if you choose a detour instead of facing the problem upfront, you may overcome some temporary difficulties, but you won’t find the real answer. The real answer is always on top of the mountain.

3. Today’s Problem Is Tomorrow’s Laughter

If you learn constantly, what seems difficult now, tomorrow will seem like a joke. Not only once I hit “impossible” situations in my coding, but staying with them long enough made them fade away. I remember the feeling of frustration and powerlessness every time I had to learn something new. Every time some new class showed up, some new algorithms appeared and I felt like I will never finish. But I did. And I laughed at my own frustration afterwards.

If you really take the time to look back at your life, you’d be amazed how far you’ve already gone. Just try to remember how was your life 5 years ago. How much was changed in your financial life? In your personal life? In your career? If you did your homework well, as in the number two above, the answer will amaze you. But if your answer will fill you up with sadness and frustration, go back to number two above and climb your mountain.

4. Good Focus Builds Good Things

The temptation of having something running out as fast you can, publishing it on the AppStore and waiting for the cash to pour in is big. Tens of thousands of programmers are hitting this road just like the gold rush in Wild Wild West. But if you look at the top 10 apps they’re all solid, verified, tested and really polished apps. Hurrying up is not a good solution. Especially in a highly competitive ecosystem like the App Store.

They say “all good things come to those who wait” for a reason, you know? You can’t expect to go on with quick fixes for ever. And yet, the perspective of waiting will frighten you up. So bad, that you’ll just run with something that works for the moment and lose sight of the big picture. Doing things incessantly, just for the sake of coping with your day to day challenges won’t take you far. Take some time to think things over.

5. If You Feel It, Do It

Many times you won’t have the tools to query your user base about the features they’d want in your app. You’re either an indie developer (like me), or the company doesn’t have a budget for creating focus groups or there’s nobody watching the forums, etc. Fact is you’ll have to rely most of the time on your own intuition when it comes to adding or eliminating features from your app. So, if you feel like something new will fit in, just go for it.

Of course, there will be times when you’ll be hit by the “feature diarrhea” but that’s a risk you’ll have to take. In time, you’ll develop a fine sense of what’s appropriate and what’s not. And you’ll grow that sense by practice, by direct interaction, by doing stuff.

That’s exactly with life decisions. When you feel it, go for it. Don’t delay, don’t ask for permission. You know better.

6. Be Neat

If you ever wrote a project with more than 5 source code files, you know that managing those source code files can be a nightmare. At this point, iAdd has almost 200 source code files. It would have been impossible to manage them without being organized and neat. By the way, iAdd was developed from the idea stage to the final implementation stage using Assess – Decide – Do, my life management framework. Without a formalized methodology in place, the project simply wouldn’t have been finished. Never.

If you have unfinished things, unspoken sentences or forgotten promises, uncover, speak out or fulfill. Don’t leave things floating around, hoping that someone else will come over and take care of them for you. Nobody will. It’s only you and your life. Keep it in order. Even if you did a mistake, a neat mistake is far easier to be repaired than a complicated one.

7. There’s More Than One Way To Skin A Cat

And perhaps more than 10 ways to implement an algorithm. In my early days as a programmer, I always was afraid there isn’t any way to do it. Now I’m afraid that I won’t choose the right way to do it. You always have more choices than you think you have. The same algorithm can be implemented in dozens of ways and a problem can be solved in thousands of ways.

That’s the same in life. If in the beginning you’ll be afraid that you won’t reach your goal, as you advance and learn, you’ll be afraid that you didn’t chose the most simple and effective way to do it. The subtle lesson here is that there are always solutions. Abundant, flowing and ready to be used. Embracing risks and daring to be different will teach you that nothing is impossible.

Nothing.

Assess – Decide – Do for Programming

Assess – Decide – Do is a simple life management framework. Despite its somehow pompous acronym, ADD is overwhelmingly simple, so simple that you may even overlook it. Every ADD cycle is based only on 3 fundamental activities: assess, decide and do. And since we’re going to talk about ADD and programming, we can borrow a little bit the object oriented paradigm: ADD is an abstract class, and every implementation you instantiate will be a subclass of it. It’s entirely up to you to create your very own ADD implementation in whatever area you want to improve. For instance, I already wrote about ADD for relationships, and will write about several more topics soon.

In today’s post I’ll sketch some outlines on how ADD can be used for software development. I do not claim to give you something complete, nor even formalized, but I’ll do my best to give you something you can use in your day to day coding activities. Being so simple, ADD gives you a lot of room on how to implement it for a specific area, as long as you respect 2 simple rules:

- at any time you can be only in one realm, being it Assess, Decide or Do
- the quality of the implementation is given by the Flow, or by the smoothness you achieve in traveling from one realm to another.

If you’re new to my blog, or never heard about ADD like this before, feel free to read the introductory series.

Assess For Programming

The assess realm is where you find out how your product / service will fit in the real world. Most of the time you already know that, because the client gave you some specs. In that case you can safely switch to the Do realm, and start coding. But there are situations in which you have to write something from scratch, to implement a new idea, to create a completely new service. Assessing comes especially handy in those cases.

In my experience I found at least 2 ways to speed up the assessment process: one is mind mapping, the other is role playing. At some levels those two can overlap.

Mind Mapping

One of the big advantages of mind mapping is its multi level structure. You can create a document with multiple levels, all accessible from the same point of view. This is especially useful in programming, since the initial phase of every new software project involves a lot of levels, from prototyping, functionalities, user interfaces, architecture and so on.

I find mind mapping to be especially useful for capturing new projects ideas. New ideas have this tendency to pop up in the most unexpected places and at the most unusual times. So, I keep my mobile device, which happens to be an iPhone, packed with a mind mapping application, which happens to be iBlueSky just in case. I think that 75% of my new ideas come from mind mapping them first in my iPhone.

Role Playing

Most of the time you write code for somebody else. The man who pays the bill is usually the client, but the real user of the app will not be the client. The real user will be the one who uses the app. One of the most interesting ways in assessing your programming is to do some role playing. Impersonate the user. Try to act and do as he will act and do. In the initial phases of a project, role playing is fundamental as it will reveal many of the functionality you didn’t even think at.

Of course, not all the time you’ll succeed, this is why outside focus groups are usually the next best thing. Unfortunately, focus groups are pretty expensive. One cheaper alternative would be to use a community of beta testers, usually created in some social networking sites like twitter or facebook. It’s a little bit unusual to use beta testers for prototyping, their role comes a little bit later, but if you can get together a team of fans or close friends to help you with this role playing game, that would turn out to be a very good asset.

At some point, role playing and mind mapping will overlap. You can start with a mind map about the interface and create several branches for each type of user you can imagine. You can role play with a mind map too.

***

Now, we talked about how you can assess, but nothing about what you can assess. One of the reasons for being a little bit cautious is the fantastic diversity of this topic. You can’t really create a cheat sheet of what to assess on such a divers field like software development. You can’t create a “one size fits all” approach here. But even if the software development area is so huge, I think we can find some common ground. Take what follow merely as an orientation map, rather than a cheat sheet.

Goal

• what is going to do the app? (usually in one phrase: Office is making text processing, Photoshop is making image editing)
• what is the problem that the app is going to solve? (some software creates more problems that are solving)
• how long the app is going to “live”?
• where is going to live? (operating system, device, programming language)

Features

• are the features atomic? (you can do the same thing from two insertion points?)
• are the features congruent with the goal of the app? (over packing with features)

Architecture

• if there is an OOP approach, class definitions, if there is a procedural language, function definitions
• modules / screens / menus
• semantic grouping of features (same like modules above but in a more abstract way)

Interface

• functionality wiring
• windows / buttons / links placement
• insertions points

Post launch behavior

• there will be some support?
• there will be updates? how often?
• there will be a constraint for some operating systems / devices?

Unless you already have in place a more formalized process for assessing a software project, that should give you a start. It’s important to mention that some of these sections will be re-assessed after a decision.

The “Decide” Realm – Backfiring

One of the most important characteristics of this realm (from an ADD point of view) is that in the software development, any decision will most likely backfire you at some point. Unless your assessment has been perfect, you will be facing some serious issues with your decisions and will talk about the reasons for that in a moment.

But first of all, what you decide in software development? Well, everything you assessed in the previous realm. In a perfect world you should have  a list of features, hundred of prototyping wireframes and a ton of crystal clear specs, and then only chose from them. In practice is not that simple. Not always the user interface will agree with some functionality and not always the architecture will be totally compliant with the operating system or programming language.

Decision in the software development process should be more close to compromise than in any other process. If you look for black and white decisions you will shoot yourself in the foot, sooner or later. And the main reason for that is the speed of technology. If you chose something now, you can bet it will be obsolete in 6 months. Your decision will be outdated. So, instead of looking for the perfect decision, you should look for the best decision in the moment.

There is no other field in which change is so present as in software development. Every 6 months a new technology appears and the change is fantastic. The users are changing behavior every 2-3 years. 5 years ago link directories were huge. 3 years ago hi5 was riding the wave. Now it’s Twitter and nobody really knows what it be tomorrow. The decision of staying with a specific platform will always be questionable.

That being said, let’s see how you can implement a consistent decision strategy.

1. Think in milestones – In software development, milestones are called versions. Limit your decisions to the next available version. Don’t plan too far, don’t plan to loose. Limiting the decision to the next available version means promoting the features and interface changes for a limited timeframe. Only until the next version.
2. Never change a decision until you implemented it – That comes from personal experience. I developed a web platform with hundreds of thousands of users and millions of visitors. At some point we decided it’s time to upgrade. But after a while we decided to stop. That was a mess. We should have follow the initial decision and after implementing it assess our success or failure.
3. Make the decision transparent – if you work with a team, communicate the decisions often. if you’re an independent developer keep a journal of your decisions. You already may have a tool for project management, but it’s especially useful to note not only the overall progress but your decisions.

The “Do” Realm – Writing Code

The “Do” realm in software development consists in writing code. Yes, that’s everything you should do. You know the features, the interface, you decided what you should do until the next version, so everything you have to do is to write code. But every guy who wanted to write a “Hello World” program knows that things are way more difficult than that.

Usually, the “Do” realm is very close to the “Assess” realm in software development. Every time you finish some code, you go testing and see if everything is ok. And you do that constantly, until you reach a certain milestone.

The main advantage of using this ADD framework is that you presumably have everything ironed in the first two realms, Assess and Decide, and all you do now is writing code. But you will go back to the Assess and Decide realm pretty often, until you reach a certain level of functionality.

***

Do you have other experiences with software development? Do you find value in this post? Do you have something to add? I’d love to hear about that in the comments.

Thesis Hooks for Twitter, StumbleUpon, Digg and Reddit

I love my wordpress theme, I really do. In case you haven’t noticed so far, this is thesis, one of the best commercial themes for wordpress. I don’t like it only for the crisp appearance and nice layout, you can get that nowadays from any decent free wordpress theme. What I like it for is the unparalleled flexibility of the backend. Not only it has 2 different admin pages full of options but it comes with one of the best features in the PHP frameworks: hooks.

Now it’s time to take a break and announce to our precious reader that this post will be a moderately technical one (yes, I know PHP pretty well, among other different skills ) and it will involve some coding. Now, let’s explain what this is all about.

Take Care Of Your Users

I use several social networking sites these days: StumbleUpon, Digg, Reddit and of course, Twitter. During the last few months I managed to attract a fairly amount of traffic from those services. To be honest, this traffic exceeds by far anything I get from search engines. And what I really appreciate at this type of traffic is its “human” touch. I might get some huge impact from a lot of bots that are searching for “iPhone 3g applications” (btw: I rank pretty well for that) but in the end what counts are the real persons who are seeing my posts promoted on the social networking services.

So, I thought it would be courteous for me to let those people know that I know from where they are coming and to start a little bit of interaction with them. I decided to have this interaction on two very hot spots in the wordpress territory: just before the post and just after the post. Sidebars, header and footer are not so hot when it comes to user action, the content rules. So, I wanted to have a simple line that would say hi to the visitor and tell him I’m on that specific social network too and a little reminder to help him promote the post, and another simple line in the end, letting him know how he can befriend me on those networks.

Pretty simple, of course. I know you can get tons of social networking features packed in a number of very specialized plugins but I didn’t wanted to use another plugin for that. I wanted to keep it extremely simple and easy to control. So, here’s how I did it (don’t worry now for the technical part, all the source code is packed and ready to download at the end of the post). (more…)

Taxonomic Twitter

In another post about Twitter I wrote extensively about the implications of this service from a behavioral perspective. It seems that I’m quite in a “twitter mood” lately since I’m writing another post so close to the first one and I’m planning another one for the upcoming days. Right now I would like to share something more technical about this.

It’s about an attempt to make Twitter even sharper and thinner, by using some sort of taxonomy, or in plain english, a method of grouping together posts by putting “labels” on them. Twitter already has a max limit of 140 characters for each post, and chances for this to grow up are likely to be zero. At least for now. So, in order to increase the readability of the tweets, all work must be done “inside” this 140 characters limit. And the way they’re trying to this is by using some extremely scaled down mark-up language.

They’re called hashtags and they are a way of identifying zones of related content. For instance, if you’re going to tweet a lot about raw food, you can insert somewhere into the tweet something like this “#rawfood”. The “#” sign will have the role to identify the string after it as a marker. Everything with a “#” in front will actually become a label. So every time you will be tweeting about raw food, you will group your tweets into a larger category of possibly related tweets. If somebody else will tweet about the same things and they’ll use the same marker, your tweets will be grouped together.

Using Hashtags Implications

First of all, there will be less room for the actual information. Every hashtag will eat some space out of the 140 characters, leaving less space for the original content. Chances are that your content could be grouped in more than one category, or marker and you’ll be inclined to use more than one hashtag in your tweet. If a consistent API would be provided for working with those hashtags – and chances are that there will be some hooks sooner than we think – then a lot of applications would be using that. Turning Twitter into a searchable catalog is just around the corner. There is a great potential for advertisers and even for people who are trying to promote their blogs or products. It would be the easiest way to direct your tweet to the intended category of readers. (more…)