My Year in Training and Assessment (Part 1/2)

2018 has been a really busy year for me. Not only did I have to grind at a job where I was (and still am!) struggling, I had a woman I was seeing (and whose finger I put a ring on in that same friggin' year!), and I was in school.

What was I studying, this time? Nothing directly tech-related. I was taking my Advanced Certification in Training and Assessment (ACTA), certification necessary to become an instructor in any academic setting. Did I harbor aspirations in that direction? Not exactly. But it certainly was riveting subject matter.

How it all began

Back in 2017, the startup I was working for, had folded. I was out of a job again, and soon found myself interviewing at a training institute, for the position of programming instructor. I've had prior experience teaching, and part of why I was putting up web tutorials on this blog is because I firmly believe that part of what helps a developer grow, is the culture of sharing, and the act of imparting knowledge. So the position was interesting enough for me to give it a shot.

Surprise - my interviewer turned out to be my very first programming lecturer from Temasek Polytechnic! His hair was all white now, but I remember the guy. In fact, every time I pick up a new programming language, I can kind of hear his voice droning on about If blocks, For loops and arrays.

Over a pleasant chat, it was revealed that I needed an ACTA to even be legally allowed to teach. I would have taken it right away, but he informed me that upon turning forty, which would be almost half a year away, I would be eligible for a ninety percent discount on the school fees. Now, to someone who's out of a job, a few thousand dollars is nothing to sniff at. I soon gained employment somewhere else, but resolved to revisit the subject of obtaining this certification in the near future.

With that in mind, once things stabilized at my job, I signed up for the next available ACTA course. I would be in classes twice a week, from 7 to 10 PM. It would be a bit of a squeeze, but I'd make it work.

The first day

The class turned out to be filled with professionals from various trades. There were even a couple of actual trainers in there. Our instructor for this module was an elderly gent with a reassuring demeanor. To get all of us to know each other better, he had us play a game.

Breaking the ice.

We formed a circle. The first one would state his or her name, preceded by a descriptive term whose first letter should match the first letter of their name. (ie, Responsible Robert, Jolly Jacintha, etc), their occupation, how they best learned and what knowledge they hoped to gain from this course. And then the next in line would repeat the previous trainee's name, along with his own, and repeat the sequence. Which meant that I, being the the thirteenth, would have to repeat twelve names. Luckily, the instructor had written down the names as we went along, so if we were in any doubt, we could refer to the whiteboard.

And then it was my turn.

To my astonishment, I could repeat the names and descriptions of all twelve of the preceding trainees without referring to the whiteboard. Not even once.

"... and I'm Terrible Tan. I'm a software developer..." Here, I paused, wondering how to answer the next question. Then it came to me. "...I learn best through repetition. And I hope that by learning how to teach others, I can become a less terrible software developer."

Why "Terrible"?

Some asked me why I chose "Terrible" when the others were using terms like "Jovial", "Noble" and "Nice". I wasn't simply being cheeky, nor was I having a serious inferiority complex. You see, I am a software developer. And by definition, we software devs are all terrible. There is so much tech knowledge out there, and all of us, even the most knowledgeable ones, know but a fraction of it all. The key to improvement is to first acknowledge how much we all suck, and how much we each have to learn.

Someone who does not think he has anything to learn, is simply predisposed to not learn anything. That's just the way it is. A software developer cannot afford to think he is anything but terrible. That leads to false confidence, and eventually stagnation.

Why "Repetition"?

Each of my coursemates had had their names repeated over and over by the time it was my turn. The first one's name had been repeated thirteen times, the second one's name twelve times, and so on.

I'm not the brightest bulb in the box; I've known that since forever. I can't be told something once and immediately understand. But when I learn something, I get good at it by repeating it endlessly till it becomes second nature.

Why "better software developer"?

At first, in my new job, I was too busy struggling to even consider evening classes. However, an encounter with a colleague changed that.

Now, I have nothing against this guy personally. For all I know, he could be a totally awesome dude outside of the office. But he was exactly the kind of person I dread working with - loud, combative and dramatic. Add that to a ton of insecurities that seemed to compel him to constantly toot his own horn about his "workaholism" and drive... and you'll see why having to work alongside him made my job a lot less pleasant than it should have been. Also, his code sucked monkey balls... but that's neither here nor there. We'll speak more of this guy another time. What's relevant here is that a few months in the job, he got an offer from another company and decided to tender his resignation. And that, of course, involved handing over stuff.

Aww, poor baby.

Halfway through one of the knowledge transfer sessions, he asked us if we had any questions. When he was answered with an awkward silence, he threw a tantrum and started lecturing us about how he used to have many questions when he was in our shoes, how we just expected to be spoonfed...

Jesus, talk like that wasn't going to induce me to ask questions, that was for sure.

We were there as a professional obligation, and doing our best to absorb. We weren't here to listen to him yammer on about how enthusiastic and driven he was compared to the rest of us. I certainly didn't feel like asking any goddamn questions. All I felt inclined to do was wait for him to shut the hell up so I could get on with my work. Pro tip: Handing over work is a basic professional courtesy when you're leaving the company. So, if you're ever in the position to hand work over, stop acting like you're doing everyone such a huge fucking favor, OK?

And that, in a nutshell, was what convinced me that being a professional tech - in fact, any professional - required skills in knowledge transfer. Communication. You can be a really gifted tech, but if you can't transfer knowledge, your usefulness is pretty limited, isn't it?

In retrospect

The instructor, later on during the course, informed us of something I had been half-suspecting - that this icebreaker game had actually served a higher purpose other than getting to know one another.

Firstly, it was meant to show the lecturer who was more or less predisposed to learning. Those who had cited interest in teaching, or interest in the certification for career advancement, were sufficiently motivated. Those who were here simply because they needed to spend some SkillsFuture credits, less so.

Secondly, it was meant for each participant to self-examine how he or she best learned something. Different people learn differently, and being able to accept that is one of the basic requirements of a trainer.

Self-reflection.

The third purpose, I suspect, was psychological - for each participant to present their own self-concept to the class. Whether or not they were "Clever Chandran" or "Slow Serena", each participant's self-concept was something that could affect the speed at which they absorbed and digested new information.

Next

We'll go into more detail about what went on during those classes. Be back soon!

Ten Principles of Adult Learning Applied to Software Development

Late last year, I started taking certification in teaching. How I embarked on that path, and why, is a story best left for another day.

As part of my research, I've been reading up on Garry Mitchell's Ten Principles of Adult Learning as outlined in the The Trainer's Handbook: The AMA Guide to Effective Training. And uncannily enough, these concepts seem way easier to understand when applied to software development. In fact, some of these principles mirror the observations I've made regarding software development over the course of my career.

1. People learn only what they are ready to learn.

This usually means that people tend to be more receptive if they perceive that what they are about to learn, is useful to them in some way. If it's important to know that stuff. Simply put, not many people learn something for the sake of learning something. It's a means to an end. They have to justify the time and effort invested in learning.

This happens a lot in software development. The domain being so wide and varied, there's always something to learn and many software developers are constantly adding to their arsenal of knowledge. Not just because they love it (though generally, they certainly do) but because in the software development industry, conventional wisdom states that they should.

Learning to configure a router.

Even then, software developers tend to choose topics they think are more pertinent. A console programmer would generally pick learning network security over web typography. A web developer would place more importance on improving his CSS than learning how to configure a router. I don't claim that this is the right approach - the fact that I'm undergoing a teaching course suggests I'm a fan of cross-disciplinary training - but that's how things are. People learn what they perceive to be of (preferably immediate) value to them.

2. People learn best what they actually perform.

Confucius had this to say regarding "performing".

"I hear and I forget. I see and I remember. I do and I understand."

Get your hands dirty, sunshine.

It's not a deliberate thing. Lessons are more readily absorbed with hands-on experience. And you will see this in spades, in programming. Reading code, knowing the right terms to use, understanding algorithms - that's all well and good. But actually diving in and getting your hands dirty, watching your code come to life as you type in those commands - that brings your absorption rate up to a whole new level.

Sure, a guy could learn the basics of Database Normalization, all the way to BCNF. But until he actually gets to work with a database schema and preferably build one up from scratch, all of it remains theoretical.

3. People learn from their mistakes.

The nice thing about getting things right, is that you learn one correct way to do it. The nice thing about getting things wrong is that you learn one incorrect way to do it. And if you make many mistakes, then you learn many ways not to do it. And if you learn fast enough from your mistakes, you never commit them again, ever.

Don't be afraid of screwing up. "Screwing up" is just another term for "experience".

Mistakes happen.
Learn from them.

In software development, the program rarely runs properly the first time. No, the more moving parts a piece of software has, the higher the chances of something going wrong. But solving bugs is one of the many ways a developer learns, and it's arguably one of the most vital skills in the industry. The more mistakes you make in the course of writing a program, the more experience you get. Subsequently, you either introduce less bugs into your code, or you learn to find them fast. Either way, it's growth. It's good.

4. People learn easiest what is familiar to them.

When something in front of you looks similar to something you've experienced before, that enables you to pick it up faster. After all, you already know part of it, right? Being able to relate a new piece of information to what is already known, helps people to absorb and retain that knowledge. If you've learned to ride a bicycle as a kid, learning how to ride a motorbike arguably requires you to mount a learning curve less steep.

Learning to ride.

Take these three code samples, for example.

PHP

echo "Hello World!";

Java

System.out.print "Hello World!";

Ruby

print "Hello World!"

What do they have in common? They all write a sentence Hello World! on screen. They may be in different programming languages, but boy, do they look similar. When a developer gains enough proficiency in one programming language, that enables him to pick up other languages faster. Because the languages do largely the same thing at basic levels of use, and if you've already mastered those basic levels, learning how to do them in a new programming language isn't much of an issue.

For a more meta example, look at what I'm doing with this listicle. I'm deepening my understanding of Gary Mitchell's Ten Principles of Adult Learning by applying them to a domain I'm more familiar with - software development!

5. People favor different senses for learning.

We've generally got five senses. Some have less. Some of us claim to have six! The point is, the eyes are not the only channel via which one absorbs information. People can do the same by listening to lectures, songs and readings. Chefs may learn the exact amount of salt to put in the soup, via smell and taste. You get the idea!

Learning in the kitchen.

Sensory input is converted into data, which is then processed by the brain and stored as information. Any sensory input, not just visual.

Ever watched a programmer use an IDE, and wonder how he manages to get all that weird code typed without even touching his mouse? Shortcut keys. The programmer gets attuned to where to place his hands on the keyboard and how far to stretch his fingers. Admittedly, I haven't gotten to that point yet. Perhaps one day...

6. People learn methodically and, in our culture, systematically.

People just don't absorb all that knowledge in one go. They learn it in small bites, incrementally. It's like eating a pizza. You don't stuff the whole goddamn thing in your mouth at one go, do you? For starters, your mouth just isn't large enough (though if it is, congratulations I guess). No, you eat the pizza slice by slice, bite by bite. You chew, swallow, reflect on the taste, then line up the slice in your hand for another bite.

Slice by slice, bite by bite.

And that's how it is with learning. You can't rush it. Stuff has to be learned in a logical sequence for it to stick.

In software development, we see this when fledgling programmers start writing code. They first learn primitive data types, and simple operations. Then they may learn conditionals and iterations before progressing on to hashes and arrays. But they certainly won't learn jackshit if you throw data structures, iterations and bitwise operations at them all in the space of fifteen minutes!

Also, in the domain of Human-Computer Interaction, we usually apply Miller's Law, also known as The Magical Number Seven, Plus or Minus Two, where the number of objects an average human can hold in working memory is about 7. This means that when designing a user interface, it's considered good form not to overload the user with too many buttons and icons at once.

7. People cannot learn what they cannot understand.

People can memorize stuff - it's just not a terribly effective way to retain knowledge. A better way to learn something is to understand it. And a better way to help people understand something is to keep things simple. Don't complicate stuff unnecessarily.

Er, what?

Martin Fowler is the creator of this classic software quote...

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."

Here's some JavaScript code. It represents how I top up my Ez-link card over the course of 10 days. If the remaining balance is less than 5 SGD, I top it up by 20 SGD. If it's between 5 to 10 SGD, I top it up by 10 SGD. If it's more than 10 SGD, I leave it alone. Every day, I use 2.50 SGD from the card. I start out with a balance of 20 SGD in the card.

This code is readable to most experienced programmers. But probably not so much to the beginning programmer.

var bal = 20;

for (var i = 0; i <10; i++)
{
    bal -= 2.50;
    bal += (bal < 10 ? (bal < 5 ? 20 : 10) : 0);}

Now look at this JavaScript code. This is long and unwieldy, but it serves an important purpose: it details the sequence carefully. You don't have to be a genius to read this.

var bal = 20;

for (var i = 0; i <10; i++)
{
    bal -= 2.50;

    if (bal < 10)
    {
        var topup = 20;
        if (bal > 5) topup = 10;
        bal += topup;
    }
}

Which one's easier to understand? The second sample has more lines (and therefore more code), but each line only took up a fraction of your mental stack. In the first sample, the entire line was long, convoluted and definitely took you longer to read and understand.

8. People learn through practice.

Repetition, repetition... and more repetition. If you see and hear something enough times, with each repetition it gets absorbed into your subconscious. If you do something over and over, it develops muscle memory.

Have I mentioned repetition yet?

One kick... 10,000 times.

Consider this quote by Bruce Lee.

"I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times."

If this line of badassery mouthed by the long-deceased badass himself doesn't convince you, nothing will.

The phrase "practice makes perfect" does not hold true in software development because in software development, perfect does not exist. If the tech world were to arrive at perfection, all progress would come to an abrupt halt. However, practice does make better. And the more times you write code, the easier it is to write it next time round. Write that code. Make variations on it. Write it till you could do it backwards and sideways in your goddamn sleep. (I was just being dramatic there. Please don't write any code in your sleep!)

The point, of course, is that programmers, like most other people, get better with practice.

But for a more meta example, consider this listicle. I'm repeating Gary Mitchell's Ten Principles of Adult Learning, on a blogpost, in my own words. This forces me to reexamine the words in his book, and in turn, this helps me retain that knowledge.

9. People learn better when they can see their own progress.

What this means is that it helps a lot if people know they are generally on the right track. A certain amount of self-doubt is healthy; it keeps you questioning. And when you're learning, you don't ever want to stop questioning. But there comes a point where doubt slows you down and hinders progress. Or worse - the learner experiences no doubt at all even though his direction is wrong, and goes off half-cocked at full speed in the opposite direction. I know one of the earlier principles mentioned is People learn from their mistakes, but that helps only when they're generally still on the right track.

Track your progress!

So when people get to review their own progress and ensure that they are learning exactly what they intend to be learning, it does not matter how fast or slow they learn - they are traveling in the right direction and they know they will eventually arrive at their destination. And when they can be certain that what they've learned so far is correct, this helps motivate them to commit the lesson to memory.

In software development, this usually manifests itself in the form of specification reviews. If you leave developers alone for too long, they may end up with a finished product that is far from what was originally specified. Therefore, weekly or even daily reviews are required to ensure that everyone in the team is on board and sticking to the program, to address deviations and take corrective courses of action. When developers are secure that they are traveling in the right direction, they'll be more motivated to put their backs into it, so to speak.

10. People respond best when what they are to learn is presented uniquely for them. Each of us is different.

Being unique individuals, people will respond differently according to method of information delivery. Public speakers may prefer to in turn listen to speeches, talks and lectures. A
chemist may respond better to information that is presented in a formula, such as empirical equations. Someone with an interest in food will naturally learn faster if the information is related to food in some way. Ever watched Kung Fu Panda? That's a perfect example.

Different people digest information
differently.

Likewise, people in the software development industry can be a diverse bunch. Data analysts may prefer their information presented in charts. A database engineer may find information easier to absorb if it comes in table form.

Personally, I like reading - books, blogs and articles. I like to observe how different people relate the same kind of information. Different authors writing on, say, web security, may present the same information in their own way, and digesting all the various works reinforces my own understanding of the material.

Whew, that's it!

That was a lot to think about. Suffice to say, it's been an interesting ride so far. For some reason, this shit is endlessly fascinating. It's been a while since I got this excited about learning something that wasn't tech-related.

Oh wait... I guess it is tech-related now. After all, I just related it, didn't I?

Keep calm and Garry on, dudes!
T___T

An Instructional Experience

Knowledge transfer is an oft-overlooked skill of developers. We're often so caught up in learning that we forget to engage in the process from the other perspective - that of the teacher. Doing so can yield dividends, for in the process of imparting concepts, one's own understanding often increases as well.

Also, teaching someone to write code is basically communication, and the importance of that in any developer cannot be overstated.

Before becoming a web developer; indeed, before even starting life as a tech professional, as a teen I was giving tuition to kids to offset the costs of schoolbooks. This was a purely one-on-one gig, and it would be many years before I actually conducted a class in an actual classroom.

The year was 2001, and I had just graduated with a Bachelor's Degree in Information Technology. The economy was facing a downturn and jobs were not forthcoming. I made ends meet by taking on freelance assignments and teaching weekend and evening classes.

Weekend classes were Computer Literacy, and my youthful patience was severely and repeatedly tested teaching senior citizens how to use the Internet. If it wasn't for the fact that I was starving, I would have quit after the fifth geriatric used his mouse upside down and wondered why it wasn't working.

For evening classes, I taught SQL, a subject in which I had done reasonably well in school. This didn't go well. I was too fresh-faced; too amateurish. I'd yet to actually accumulate any professional experience, and it showed. My late grandmother (bless her) encouraged me to keep at it and assured me that looking young wasn't a crime. Little did she know how much I detested the act of imparting skills I had yet to earn.

Grandma's little babyface

Fast forward ten years later, I was a full-fledged tech professional with six years of desktop support and four years of web development under my belt. My then-boss sent me to a client to deliver a course in MVC. That was the first time I had heard of MVC. I spent the entire weekend on a crash course learning the subject. You bet your ass I was nervous... but to my surprise, not only did the tech professionals in the classroom show me an unprecedented amount of respect, they actually thought I knew my shit. One of them even privately approached me with an eye for poaching an experienced professional with MVC skills!

What the actual fuck?!

More substantial teaching experience

Another year later, an ex-colleague introduced me a pro bono gig at the Muscular Dystrophy Association of Singapore, teaching PHP to members. For those not in the know, Muscular Dystrophy is a degenerative disease that causes the victim's limbs and organs to be underdeveloped. My students were wheelchair-bound and extremely slow typists. However, up there, they were perfectly healthy.

Before I continue, I want to stress that this wasn't an altruistic act of nobility on my part, nor do I have some bombastic virtue-signalling reason behind doing this gig. My motivations were completely selfish. You see, I am a web development enthusiast. That's how I've been able to stay in the game this long. And like most enthusiasts, I'm perfectly happy to share with people who are interested. And nothing spelled interest like a bunch of guys in wheelchairs painstakingly making their way down to MDAS every week, rain or shine, to learn the stuff. If someone could display that much commitment, I was more than willing to take half a day off every week to teach them. The fact that they were guys in wheelchairs did not matter. They could have been rich privileged kids for all I cared.

Also, as mentioned before, teaching hones the skills in the subject you are teaching. And as a tech professional, I was all for it.

The weeks went by as I brought them through the concepts of Client-server Architecture, variables, operators, conditionals and iterators. The going was slow. Real slow. Having underdeveloped limbs, they simply could not type as fast as the average programmer. Sometimes even using special characters like curly braces and quotation marks was a chore. It was from this, that I learned. I saw how they got around these limitations with various devices such as special keyboards, styluses and touch-screens. One of them even drove. I had the good fortune to help her move some stuff to her car, and witnessed the way she hauled herself into the driver's seat and tucked her wheelchair into the back all by herself. I saw the way the brake and accelerator were rigged just below the steering wheel to account for her abnormally short legs. Before this, in all my ignorance, I'd never even heard of a disability vehicle. My eyes were being truly opened.

The icing on the cake came around the last few weeks of the course, while I was taking them through the concept of arrays. Every time I made a mistake in the code, they would call me out on it. Not just syntax errors, but logic errors. After every lesson, I had been providing them links to follow for further reading and revision. And they had done their reading and revision. Instead of me pointing out their errors, these little devils were now pointing out mine. It's really hard to describe the overwhelming pride I felt that day.

Epilogue

My primary motive had been to share. I won't claim that I taught them extremely well, but somewhere along the way, I had helped fan the flame of my enthusiasm and it was starting to spread. And sometimes, transfer of enthusiasm is more valuable than the transfer of knowledge.

Soon, I changed jobs and my new employer no longer allowed me to spend my leave in regular half-days. At that point, I was no longer able to schedule classes. However, since then, I've started this blog and put up web tutorials. In some form or other, I want to continue sharing.

Now that was a really classy experience!
T___T

Ten ways to hone your craft

Web development, as an industry, is in a process of constant renewal. And to keep afloat, if not flourish, it's every web developer's professional duty to ensure that the tools in his arsenal remain sharp, relevant and battle-ready.

Easier said than done, right? It's simple enough, really. Here are ten ways. You don't have to practice all of them, but I think they're a good start and hope they'll help you. Some of these ways overlap each other in small ways, but they're largely distinct.

Keep going through those motions.

1. Practice

Yes, yes, I know, call me Mr Obvious. I hate to rely on the overused cliche "practice makes perfect", because it's patently untrue. Practice does not make perfect. There is no such thing as perfect, at least not in an industry where things are constantly changing. Practice, however, does improve your skills.

Get an account at CodeWars, TopCoder or something. That's where developers all around the globe present programming problems for their fellow programmers to solve. Not only do you get to train, you also get to see how other programmers solve the same problem. It's an eye-opener.

Tinker with technology when you get the chance. Experiment and explore. Push those limits, and find new ways to do things. Rock that code.

Absorb whatever little snippets of
information in your spare time.

2. Read

Blogs, Tweets, tech news, job advertisements. Tech forums like StackOverflow and Quora, where fellow web professionals exchange ideas and opinions. Keep up to date with web development trends. Nothing says sloppy like a web developer who doesn't know about anything happening in the web industry.

Of course, keeping up with the news isn't limited to "reading". There are PodCasts to tune in to and software release videos to watch too.

Write anytime, anywhere.

3. Write

Write your own tech blog. Sound like a tall order? It did to me. I did it anyway, loving every minute now. Writing down all my discoveries and ruminations has deepened my understanding of my craft.

Don't be afraid of coming across like a noob. There are plenty of developers blogging on the internet and gleefully making fools of themselves. Join us! Blogging is also an internet tool. Add that tool to your arsenal!

Time to patch those holes.

4. Patch

Think you know what you need to know? Think again. Everyone has gaps in their knowledge. Everyone. No one can know everything, not in this industry. The worst thing you can do is to suck so badly that you don't even know what you don't know.

Make a list of gaps in your knowledge, and work to resolve them through research or study. I've got a list of my own - higher-order functions, regular expressions, closures, promises... just to name a few. Everytime you come across a term you don't understand, add it to the list of things you need to Google.

Oh and yes, Google is your friend. Wikipedia's a close second!

Hit the library.

5. Learn

Take a course. A developer boot camp or a technical diploma. Take your pick! Stuff can be self-learned, of course, but there will be times you need a bit of hand-holding, a nudge in the right direction.

Or simply pick up a book from the library and try to learn something new. A programming language, application framework, database... anything. You won't become a guru overnight - long way to go, pal - but it's a start!

Demonstrate stuff.

6. Teach

"Those who can't do, teach." That's a load of crap. This is highly misleading. Your skills don't exist in a vacuum. They blossom through interaction with other practicioners. Whether it's showing your fellow developers how to achieve that cool CSS effect or teaching QBasic to a class of young impressionable teens, having to explain stuff does increase your own understanding.

You can no longer be satisfied with "doing", and having stuff simply work. Now you'll have to explain why it works. That, in itself, is just about guaranteed to bring your skills up several notches.

Knowledge transfer - don't knock it.

Hone your interview skills
by... well, interviewing.

7. Interview

Like it or not, presentation is a huge part of being a web professional. Any professional. Knowing how to express ideas and impress people is often more important than the gazillion programming languages you've listed in your resume.

If nothing else, it'll show you where you stand in the industry. Interviewers will test your technical ability. They will examine you, and force you to show your best side.

And when that offer letter arrives, whether or not you ever intended to change jobs, it's a huge boost in confidence you just can't put a price on. Time well-invested.

Sneak peeks at other peoples' stuff.

8. Steal

Know that great web template you saw while surfing? Or that nifty user interface? Or that superb search function?

Steal it. View the source code, learn how it's done. You can't think of all the great ideas out there. Trust me, they'll be flattered. That's why people put their work on the web - so it can inspire others the way they were originally inspired.

More precisely, make your own version of it. Recreate the functionality using the tools at your disposal, and if possible, improve it. Oh, that code was done in Ruby and you only know PHP? Well, you could learn Ruby (not a bad idea) or you could replicate it in PHP (not a bad idea either!). Firstly, it helps you practice. (See Point 1) Secondly, it helps you see that you're capable of what others are doing. Thirdly, it trains you to reverse engineer.

Keep busy.

9. Side Projects

You're probably thinking that after a long day at work, the last thing you want to do is hammer out more code. That's certainly your choice, but consider this - any project you embark on in your spare time, be they freelance jobs or just your own pet project, is likely to benefit from the expertise you've gained while at work. Conversely, the new insight you gain from working on your own stuff outside of work, will trickle into your work.

Also, your personal projects will likely not be affected by pressing deadlines or asinine client requirements. You have greater control. You'll finally find out just what awesomeness you can pull off when nothing's holding you back.

Use others while making
yourself useful. Stay connected.

10. Network

Web development's a very diverse field. One person can't know everything (fun trying though!), so the next best thing is to have a network of people you can talk to and seek advice from. They can be specialists in programming, SEO, databases... who may also have blind spots in their knowledge they need your help with.

An extensive network is good for news exchange, job referrals and idle chat. It develops your interpersonal skills and insight.

Get cracking!

Your craft isn't going to hone itself. An idle developer is a developer in danger of extinction. What, you thought this path was going to be a bed of roses? Boy, do I have bad news for you, sweetheart.

Don't be a tool. Sharpen your tools!
T___T