That strange feeling that comes with achieving that prize

It's an odd sensation. Early this year, I received another salary increment, which put my pay bracket - and subsequently, my total monthly income - at three times what it had been back in 2012. And it is strange because back then, I was a struggling web developer who was regularly pulling twelve-hour workdays dreaming of one day making a certain amount of money every month. And what was that lofty goal, one might ask? Why, that amount I was aspiring to, is less than half what I make now. Significantly less.

In other words, I'm making more than I ever wanted to.

Was it inflation? No. I did the math. Even with inflation, I'm still making substantially more.

Sure, I make a lot less than many people who are younger than me. But given the fact that I spend like I'm still on that miserable monthly wage twelve years ago, I can feel a hell of a lot more secure than the average millennial.

How?

Spending within your means is merely one way of saving money. Any financial advisor worth their salt will be the first to tell you that saving money isn't the way to increasing your income. It's just a way to minimize your chances of becoming desperately poor. Of ensuring that you always have something in reserve. But it will not make you rich.

It's not working hard and education, either. Sure, I did both. But neither of them, on their own, or even in tandem, got me money. No, it was keeping one eye open for the next opportunity and ruthlessly moving on for a significant pay bump. I always (well, mostly) enjoyed my work, but made sure never to get too comfortable. My first disastrous six-year stint as a desktop support guy taught me that much.

And that brings us back to the issue of always having something in reserve. Living a very financially sustainable lifestyle is what gave me the freedom to just move on whenever I felt like it. No waiting for bonuses or bullshit like that. No, when the TeochewThunder Train moves, it moves.

The train moves on.

Living like you're on your last dollar isn't a lot of fun. Let me tell you what is even less fun - actually being on your last dollar. Living from paycheck to paycheck. Relying on the goodwill of friends and relatives. Taking handouts from the Singapore Government. Relinquishing your last shred of dignity to survive another month. Thankfully I've never had to go that far, partly because I never allowed myself to.

I lived as though I was on my last dollar for years out of necessity, then I started living like this so that I would never again need to live like this.

I mean, what is money really for? Overseas vacations, fancy restaurants, the trappings of the high life? Rubbish. Those are irrelevant. What money ultimately really gets you is freedom. Freedom to do whatever you want, on your own time. I want money so that I don't need to worry about not having any.

That's all it is. That's all it ever was.

And now...

I work a lot less. Partly because with experience, I can recognize lost causes and dial back accordingly. I can get more done with less effort.

And partly because at this point, I have very little left to prove. I'm 47. In ten years, I'm either dead, retired, or well on my way there. If not sooner. I have no kids, or even pets. Being recognized as a valuable member of the company does nothing for me psychologically or emotionally. I lived, I will die, and in my time here I did nothing that would shake the world, or echo through the centuries to come. I am no better than the average schmuck, and I'm perfectly OK with that.

I lived, and I will die.

And also because I've built up a respectable nest egg... and unless I lose it all through a random act of stupidity, I'm good. Thus, I'm not afraid of losing my job or anything like that. I can work without that millstone hanging around my neck. I can actually enjoy my work. It can't be overstated how important that is.

Final Notes

I've been seeing Singapore Parliamentary debates about how ineffectual the WSQ framework is with regard to improving employment. People have been complaining about not being able to get good jobs despite upskilling and upgrading. That's because it's not meant to work that way. The Good Jobs Genie isn't going to suddenly appear and let you have your pick of jobs just because you got a certification in whatever. Upgrading is not a silver bullet that will solve all your problems. It's just one step in a series of many steps, some meant to be taken concurrently.

You owe the world nothing, and in turn, it owes you nothing. Whatever you have is what you can get, and more importantly, what you can keep.

$ee you later!
T___T

Five Dimensions of Competency, redux

I have written in the past about the Five Dimensions of Competency as defined by Workforce Skills Qualification (WSQ). At the time, I was learning about WSQ and was about to be tested on my knowledge, so writing about it seemed a good way to really drive home the knowledge.

This theory seemed sound, until I found a better teacher - a real, living example.

This guy was a colleague, a fellow software developer who lasted exactly one year in the organization. And when you're a contractor, serving your first contract with the company to completion isn't that big a deal. In fact, if it's a renewable contract which doesn't get renewed, it's almost akin to a termination of services.

Now, I'm not saying this guy was lousy. He was young, energetic and possibly technically better than me. But as mentioned, competency is measured in five dimensions. Today, we're going to take a look at dimensions of competency where he did and didn't make the grade.

I'd like to say that this guy wasn't a bad guy. He was easy to get along with. Not terribly mature, but at the age of thirty there's plenty of room for growth.

1. Task Skills

Individually, this is where he shone. His technical knowledge was solid enough. He was certainly able to code. But of course, it has to be said that if software devs were judged solely on their ability to code, a huge portion of us would pass quite easily. The other stuff matters just as much, if not more.

The ability to write code.

Unfortunately, while his code worked, he had this tendency to be slipshod where code formatting was concerned. He didn't indent or space out his code properly, and even remarked to me on more than one occasion that these things were not important. He left rubbish comments all over the place - comments that made sense to him alone.

You know the kind of guy who writes "fixbug" in commit remarks? He was that guy.

Not only did he do all this, he didn't seem to understand why it was such a big deal. Not that I don't make mistakes, but when they're pointed out to me, I tend to know why they matter.

Knowledge: Pass
Skill: Pass
Attitude: Fail

2. Task Management Skills

Task Management Skills are mostly about prioritization, and here there's not much to say because as far as I can tell, he was never assigned anything substantial and therefore never had the need to prioritize.

Working overtime.

A plus point: he had no issues working overtime to get shit done - what was suspect was the need to put in that much overtime in the first place. Diligence wasn't the issue; how much of that diligence was productive, was the issue. I recognize this because I've had the same problem in the past.

Knowledge: ?
Skill: ?
Attitude: Pass

3. Contingency Management Skills

Most of our work was implementing new features, and fixing bugs. This guy could code, but sometimes his bug fixes didn't solve the problem, and even resulted in new bugs. He seemed to have an aversion to testing his code.

Bad patches and fixes.

I mean, we're talking about the really simple stuff here. If the bug is in a formula which is supposed to produce a result, isn't it reasonable to expect that if you applied a fix, you would test for the correct output?

Nope, he didn't do it. One of my strongest memories was asking the QA to reassign a bug fix to this guy because I was being swamped with work, saying "it's so simple, there's no way he can screw this up". The QA didn't look so sure, and after the "fix", I realized just why. The output was still wrong.

Now, at this point, this wasn't a matter of aptitude. His heart just wasn't in it.

Knowledge: Pass
Skill: Pass
Attitude: Fail

4. Job Management Skills

Now, this is where he really tanked. Where writing code was concerned, we had to ensure that our work was maintainable, and as mentioned earlier, he just didn't think stuff like appropriate comments, proper indentation and spacing, was all that important.

But that's just one thing.

You see, as professionals, we have obligations other than writing and testing code. As contractors, we also had to fill in our timesheets and clock our hours. He received multiple warnings for failing to do so.

Locking your workstation.

The most important area where he dropped the ball, was security. Not coding security, but basic security such as locking his screen when he went for a smoke break, or even leaving his docking station unlocked the entire damn day. None of these had anything to do with programming; it was just good old-fashioned sloppiness.

Knowledge: Fail
Skill: Fail
Attitude: Fail

5. Transfer Skills

Just like me, his coding skills were applied to different contexts. There were various parts of our work that required us to pivot to vastly different tasks. One day we could be working on the back-end, and another day we could be writing Stored Procedures and generating reports.

Using different tools.

The tasks I was assigned to eventually turned out even more different - APIs and DevOps as opposed to just front and back end programming - but that wasn't really his fault because those were assigned after he had departed.

Knowledge: Pass
Skill: Pass
Attitude: Pass

Conclusion

This entire exercise isn't about denigrating an ex-colleague just to look good. No, I was actually thankful for his presence. If it wasn't for a negative example to take reference from, I might have made some of these mistakes as well.

I know I've said it before, but this bears repeating - being a dev is not just about coding, and competency is not just about knowing how to code.

I have a lot to learn, and hopefully with more people making mistakes for me to observe, I'll learn a lot faster.

Competent regards,
T___T

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

The final month of 2017 ended quickly, and the subject matter of the classes was pretty fascinating. We covered different learning profiles and how different people reacted to different methods of information delivery. Looking up the internet and the library, I discovered even more stuff in addition to the reading materials.

My classmates were a fun bunch. Sure, they were mostly older folks and some of them said things I would have found cringe-worthy in another setting. Here, I tried to keep an open mind. The group discussions we were put through were insightful. Most of us tried to be nice to each other because we were depending on each other to get through the course. I soon learned that I got on better with some of the others, and even consulted one of them personally on my upcoming marriage.

Assignments

For the most part, I didn't have a problem digesting whatever information was given. A lot of it seemed to be common sense. When handing in a lesson plan, which was one of our assignments, the instructor even commented that I seemed to be getting the gist of it quite handily, and had nothing further to add. He wasn't just saying that, because he had a lot to say when others were handing in their lesson plans. On my part, I was just glad that I seemed to be on the right track.

We also had to keep a learning journal of sorts, detailing what we had learned and our reflections on it. I went a step further - I actually blogged about it. (Garry Mitchel's Ten Principles of Adult Learning made quite a nice listicle.) The act of doing so helped me digest the information and cement the principles in my head. Besides, that was actually how I best learned - via repetition and practice. My fellow coursemates thought I was this super student because I did my stuff way in advance.

I was a hardworking but woefully
untalented kid.

I'm afraid they were mistaken.

A lot of it isn't intelligence or diligence, but pragmatic time management. Every weekend, I dedicated a certain amount of time keeping the journal up to date so that I would have any problems handing in my work in March. One of the best ways to combat stress, is not to allow yourself to get into any unnecessarily stressful situations. Knowing that I'm not some extraordinarily smart individual that could produce written assignments on demand, it seemed foolhardy to leave everything to last-minute work and hope for the best.

Incidentally, it was the same way for me when I was younger. Study early, study often. I was never an A student. Mostly Bs. But boy, nobody knew how hard I had to slog for those Bs. People just thought I was really clever and shit. Word of advice: very few people are actually that clever. It takes a hell lot of work. And, of course, once again, time management.

Assessment on Classroom Facilitation

Midway through the third month, we all had to conduct lessons as part of the requirement. Each of us would decide on a topic which we would then have to "teach" our fellow coursemates. This was where I started floundering. People thought I wouldn't have a problem because I seemed quite at ease presenting to the class during lessons. What that was different - I mostly wasn't trying to impress anybody and nothing was at stake. Now, we were actually going to be assessed on how well we conducted the lesson plan we had developed, and I'm afraid the pressure got to me. No matter how much I rehearsed for the day, when it was time to actually do the job, my voice trembled.

One of the things an instructor is supposed to do, is assure the course participants that he or she is qualified to instruct them, and that they are "in good hands". In practice, if there's a way to say "I have a degree and three diplomas" without sounding like a conceited dickhole, I haven't discovered it yet. Some of my fellow coursemates had a better idea - they merely displayed their credentials on presentation slides to they could toot their horn without sounding like they were, well, tooting their horn. Well damn, why hadn't I thought of that? Because I'm an idiot, that's why.

Depending too much on
the whiteboard.

I kept the knowledge transfer small, facilitated group discussions and basically made sure items on the assessment checklist were met. Everyone was watching me because, well, I was the first to be assessed. I had actively chosen to be the first - to get it out of the way, and also, when you're the first to go, expectations are generally lower because you're expected to make a whole bunch of mistakes the others can learn from.

My chosen topic was "web development", and true to form, I had elected to prepare web pages instead of presentation slides. The rest of it, I reasoned, I could use the whiteboards for. Eliminate the chance of being stymied by technical failure. Surprise, surprise. The classroom we ended up in, had whiteboards that were blocked by heavy desks and assorted clutter. And here I thought I was being so clever. What the fuck, right?

As the "lesson" went on, I realized that very little of it was going the way it had played out in my head. I was nervous, my voice cracked, and sometimes I talked too fast and had too many pauses. And then the class, comprised of my fellow coursemates, began to act up.

This wasn't done out of malice - the instructor had told them they were supposed to act up so that he could assess me on how I handled disruptions. So I had people asking me blatantly stupid questions, making small talk loudly, defying instructions and so on.

Ironically, I was feeling like an utter failure by then and decided, to heck with it, I was just gonna do my thing and to hell with impressing the instructor. I totally forgot my fear in that instant. Have I mentioned that I've taught classes before? Well, when my fellow coursemates acted up that evening, I simply reacted, as if by instinct, the same way I did all those years ago. Blatantly stupid questions were shrugged off or waved away. When people made small talk loudly, I upped the volume of my voice for about two seconds, jolting them back to attention without missing a beat. When people attempted to start an argument, I told them I acknowledged their point and we could revisit this after the class. Basically, I came on strong, and backed the hell off when I needed to. The iron-fist-sheathed-in-silk-glove approach.

And I smiled. A lot.

When it was over, I went over the checklist and discovered, to my amazement, that I had covered a ton of items under "Handling Disruptions" without even trying. I hadn't even been consciously attempting to do it by the book! That was an epiphany for me - I do best when I don't try so goddamn hard.

Then it was over, and during the course of the next few weeks, I sat back and watched my fellow coursemates go through their own assessment. It was of small comfort that many of them faced the same problems I did, and some even had to repeat their assessment. It was my turn to conduct a peer assessment for some of them, and in those instances, I opted to be kind. After all, my remarks would make no difference at all to their final score, and overdoing the criticism seemed unnecessary.

E-Learning

The next module dealt with understanding the WSQ system. To that end, we were put through an E-learning program which was supplemented by webinar sessions. This was pretty dry, and the E-learning system absolutely sucked. To go into full detail about how much it sucked would be devoting too many words to it, so I won't. Again, I supplemented my learning with more blog entries, such as one about Five Elements of Competency and using WSQ Competency Standards.

My ex-boss from the startup had also completed his ACTA, and his advice and supplementary reading were invaluable. Another case for not burning bridges you don't have to. Never know when someone in your network can help you.

I was suffering from serious burnout by this time, and it was all I could do to keep my journal entries up to date. Also, the then-girlfriend and I were going through the arduous process of getting married. Let me assure you that nothing about it was fun, and mostly involved the logistics of making space for one more person in the house. More about that another time, though...

Assessment on Assessing

After the last excruciatingly boring module was the one on being an Assessor. We were trained on how to deliver an Assessment to a test candidate in a fair, empathetic and diplomatic manner. How to provide an optimal environment for Assessment. Things like that.

Assessing...

And then came the assessment... on our Assessment abilities. This involved live-action roleplaying with a prepared background scenario. We were divided into groups for this, and my group aced the entire thing without any do-overs. I can't claim any credit for this one - one of my team members was a right pain in the arse where details were concerned. He was also meticulous and not one to leave anything to chance. He prepared scripts for us to follow, and even had the bright idea of having them vetted by our instructor.

So, after we had made the changes recommended by our instructor, all we had to do was follow the script... and viola, another module out of the way.

Some drama occurred during the Assessment, things that made me come to new realizations. One of our team members lost his temper at another member. Harsh words were exchanged. To be fair, the guy being raged at, was slow to grasp the material and seemed to be going off half-cocked in the wrong direction... and this wasn't the first time either.

However, being a WSQ instructor is not just about having the skills and knowledge in facilitation of learning. Like many other professions, it is also about having the correct temperament. Often, instructors don't get a choice as to what kind of people are being allowed in the courses they are teaching. They are going to get people who are merely doing this on a whim. They are going to get the ones who think they already know everything. They are going to get the ones who aren't actually interested in the subject matter. Basically, those who are all but impossible to teach. And if we're going to lose our shit everytime someone like that shows up, maybe we should consider another line of work.

The Final Assessment

The day of the Final Assessment arrived. By then, my nervousness was gone and all I really wanted to do was get it over with. My time studying the WSQ Assessment System had all but assured me I wouldn't be failing this one (unless, of course, I failed to show up). After all, in order to justify a failure, a lot of paperwork had to be done by the Assessor. And honestly, I'd done the work. I had blog entries in addition to journal entries. And I had passed all previous modules. I can say with no false modesty that failing me at this point would require one hell of a justification.

I walked out of the assessment room with my ACTA...

Epilogue

... and on the very next day, I put that ring on my girlfriend's finger, and made her my wife. What have I done with that ACTA? Nothing to date, sadly. But it's there if I ever need it, and the experience proved enriching. Exhausting, yes, but enriching.

My fellow coursemates still hang out. Most of us are still in the original WhatsApp group we used during the course. Sometimes, we meet up to catch up. Yep, even if I never get to use that ACTA, I definitely don't regret taking that course. It was a blast. I don't know that it actually made me a better software developer, but it sure as hell rounded out my resume nicely.

Your certified Trainer and Assessor,
T___T

The WSQ Way to Self-improvement

Identifying and addressing knowledge gaps is part and parcel of being a web developer; indeed just about any technical field. I remarked on this last month, and now here's a concrete suggestion. Today, I'd like to cover one of the ways in which developers may find out exactly what knowledge they lack.

In a field as wide and varied as software development, there is a very real danger of specializing too much, or worse; not realizing where the knowledge gaps are in the first place, and what's required by the industry. Because the answer to that question varies depending on who you ask. In cases like these, we need a singularly reliable source of truth - the Government. I'm not saying that I agree with everything the Government pushes, but certification from the Government does mean that if you have such a certification and seek employment in Singapore, there are very few organizations that can argue against your certification. After all, this spec was developed by industry experts and endorsed by the highest authority in the land.

Cover

The Workforce Skills Qualification credential system was set up by the Singapore Government to set up competency frameworks across a variety of industries, so as to improve labor movement and quality control. A few of these frameworks are pertinent to web development - InfoComm and Creative Industries. For today's example, I downloaded a copy of a Competency Unit - Code Scripts to Provide Front-End Functionality for Websites - from the Creative Industries WSQ framework at https://www.skillsconnect.gov.sg/sop/portal/. By referring to this document, if you're a front-end developer, even (or especially) if you're an aspiring one, you may be able to identify areas in which you can shore up your skills and knowledge to meet industry standards.

Here's a breakdown of the spec...

Relevant Job Roles/Occupations
Assumed Skills and Knowledge
Performance Statements

Relevant Job Roles/Occupations

This basically lets you know what roles or occupations would find this relevant. Pretty straightforward there... though I can't say I agree with the term "HTML Programmer". What is this, 1995?!

Assumed Skills and Knowledge

This is a list of ideal prior knowledge for taking up training in this Competency Unit. Meaning, it'll be a whole lot easier for you to learn this Competency Unit if you know this stuff. I'm not sure that these should be optional, though. I mean, if you don't know HTML, CSS or even basic programming, what the hell are you doing trying to code scripts? Most, if not all, scripts manipulate the Document Object Model, which is the product of HTML. Honestly, having no knowledge of HTML while trying to learn scripting, is the software equivalent of attempting the hundred meter dash without learning to walk first.

Performance Statements

A list of items, in no particular order of importance, that someone should be able to demonstrate in order to pass this Competency Unit.

Pay attention to this one. Be honest with yourself as you assess your ability to perform each of these tasks. Anything you're not so great at? Anything you've never heard of at all? These are excellent starting points.

Underpinning Knowledge

Underpinning Knowledge

This is all the knowledge that should be behind the items you have performed above. There is, for example, no sense in writing a HTML page and claiming you know how to write a HTML page when you don't even know what "HTML" stands for. Or being able to write scripts that do stuff, without knowing what the lines in the script do and why they are required.

We've all dealt with those devs before, from time to time we may even be them - they're called "copy-paste programmers".

As in the Performance Statements, what's needed is for you to go through this list and see if there's anything you don't know, then start rectifying your shortfalls from there.

Range of Application

Range of Application

This is about contextualization. Not every tech job requires you to know everything under the Performance Statements and Underpinning Knowledge. For example, not every tech context requires objects... or even loops (though that would be pretty strange). So there are some examples of each Performance Statement and Underpinning Knowledge, of which a subset has to be fulfilled.

Research your competencies!

A tech career is an ongoing progress. The day you stop learning, the day you stop wanting to learn, your career is already dead - you just don't know it yet.

Use the (work)Force, Luke!
T___T

Five Dimensions of Competency applied to Web Development

According to the Workforce Skills Qualification initiative in Singapore, there are five dimensions to competency - Task Skills, Task Management Skills, Contingency Management Skills, Job Management Skills and Transfer Skills. And today, I would like to apply this to a web development context.

Why? What's the point?

Because contextualizing stuff helps me learn better. (Yes, this is one of my many, many school projects).  Plus, I like writing listicles. Let's go!

KSA

Before we continue, we've first got to understand what role KSA plays in the Five Dimensions. of Competency. A competency in any field is a measurable set of Knowledge, Skills and Attitudes behind every individual's performance. Therefore, every dimension of competency has its own related KSA.

Knowledge is the theoretical or practical know-how. It's your understanding of the subject matter - namely the why and how.

Skill is the psychomotor capability developed through training and/or experience. It's your ability to perform what you know.

And Attitude is your predilection towards doing it right. It mostly comprises of your values and your outlook. Basically, knowing that you should do something is not the same as being inclined to do it.

1. Task Skills

This is pretty straightforward. It refers to all the little tasks you have to perform while doing your job. It measures your ability to carry out a single task to professional standards.

Take for instance, writing a HTML layout off a wireframe. Is your final product responsive? Is it W3C Compliant? Cross-browser compatible?

Setting up a database.

Or, setting up a database. Are the fields aptly named? Is the schema appropriate? Fully, or at least adequately normalized? Efficient and robust?

Knowledge - Understanding compliance standards, why databases need to be structured a certain way, etc.

Skill - Being able to create code structures, schemas, HTML layouts, etc.

Attitude - Commitment to standards compliance and best practices.

2. Task Management Skills

This one takes it up a notch. It's an assessment of how well you coordinate all the individual tasks into a work activity.

Writing a web application, or even adding a new feature to an existing web application is a work activity that is made up of several individual tasks. Now, when performing that particular work activity, you're expected to architect the solution, cater for existing use cases and anticipate possible edge cases. You may need to leverage off existing data storage and probably write a fair amount of code. How well you do those tasks is not the issue here - what you're assessed on, is how well you prioritize what needs to be done first, and in what sequence. You may decide that the database is more important to you, but users are naturally going to want to look at the interface first. How you resolve these conflicts is also a measure of how aptly you are managing this activity.

Juggling it all.

Let's say you decide to work on the interface first, and manage to set up a fairly workable layout. Do you then spend more time making the layout responsive, or do you decide that displaying data takes priority? Again, it's not how well you perform these individual tasks, but how well you manage doing all this at once.

Knowledge - Understanding how different tasks relate to each other in the overall scheme of things.

Skill - Prioritizing, time management, self-organization.

Attitude - Having the discipline to stick to a plan, as opposed to just "going with the flow".

3. Contingency Management Skills

Things are going to go wrong at some point. It's one of the undisputed and immutable laws of the universe. When things go wrong, or don't perform as expected, how do you handle it? How good are you at dealing with unusual situations that arise?

Handle problems like a pro.

In web development, like any other software development, things can (and will) go wrong. The layout may turn out to totally fail when testing in Internet Explorer. The data might take a little longer to load than expected. The data displayed might even be wrong. How solid are your solutions? How quickly do you find the root of the problem?

Knowledge - Understanding how to root out problem sources, interpreting error logs and generally how to troubleshoot.

Skill - Applying fixes and solving problems.

Attitude - Commitment to solving the problem itself rather than just a surface fix (and of course, knowing the difference!).

4. Job Management Skills

Some things aren't just limited to your role alone. Very few workers function in a vacuum. You have to learn to play well with others, and interact with other cogs (of which you are one) in the entire system.

Is your code easy to read, modify and extend by your team members? Are your comments useful? Do you coordinate and communicate effectively with your teammates?

Are you a team player, or a go-it-alone cowboy?

Are you able to interact with Infrastructure for support when you need to deploy your web app? Or discuss design issues with the Design department to better facilitate the building of the interface?

Pair programming.

These questions are pertinent because the days of one super programmer doing everything by himself, are just about over. No matter how good you are, if you can't work well with others, you're pretty much useless to any organization. I'm not saying people have to like you. But they do have to like working with you. There's a distinction to be made there.

Knowledge - Understanding why your ability to relate to your co-workers, while not technical, is still vital. Use of Code Repositories, Pair Programming and Code Reviews.

Skill - Diplomacy, communication.

Attitude - Respecting the contributions of others in the final product and recognizing that everyone is important.

5. Transfer Skills

This measures your ability to apply your knowledge outside of the usual context. Knowledge and skill are limited in utility if they can't be applied to new situations.

Let's say you can write a web application like a boss. How well can you translate that to writing a mobile application?

If you can make a web app,
can you make a mobile app?

Or perhaps, you can implement stacks, heaps and all manner of cool magic using Java. How effective would you be if you had to use PHP instead? Is your foundation in programming strong enough that any language will do?

Knowledge - Understanding the different components of your knowledge, breaking them down and applying them to fresh scenarios.

Skill - The ability to accomplish different things using the same tools, or accomplish the same things using different tools.

Attitude - Being willing to drive innovation by applying your skills to newer areas. Being willing to learn new tricks, or new tools.

All in all...

There's a lot more to competency than simply being good at something, or being able to do something to a certain standard. If you can't manage your own workload, react and recover from unexpected situations, communicate with others or apply your skills to a different environment, then you're not competent enough to be truly useful. And if you're an actually talented individual otherwise, that would be a huge pity. It's not enough to be good at individual tasks because machines will beat you at this every time. To be truly competent, you have to measure your competency in these five dimensions.

Most competently yours,
T___T