Web Tutorial: Ruby Website Template Generator

One of the many repetitive tasks of web development is setting up the main HTML file, CSS and JavaScript in the correct folder. Normally that doesn't take very long, but as with all repetitive tasks, it is best automated for minimal error.

Today, I would like to walk you through a website generator program. And for that, we'll be using Ruby. It's just one of the many little things I did to help me learn the language. What this website generator does is to create a HTML file, a CSS file and a JavaScript file. It will then insert references to the CSS and JavaScript files in the HTML file, along with the standard markup.

We begin by putting in a puts statement. Simple enough?

puts "Welcome to Teochew Thunder's Website Template Generator!"

And there it runs...

Next, we declare the variable continue and set it to an empty string.

puts "Welcome to Teochew Thunder's Website Template Generator!"

continue = ""

Then we use a While loop which will go on forever as long as continue is "Y" or "y". The bulk of your code will be in this While loop.

puts "Welcome to Teochew Thunder's Website Template Generator!"

continue = ""
begin

end while continue == "Y" or continue == "y"

Let's put in some user input. First, ask the user if he or she wishes to continue, then get the input and use the chomp method to remove spaces.

puts "Welcome to Teochew Thunder's Website Template Generator!"

continue = ""
begin
    puts "Do you wish to continue? (Y/N)"
    continue = gets.chomp
end while continue == "Y" or continue == "y"

Now when you run this code, it keeps asking you the same question as long as you enter either "Y" or "y"!

We follow up with asking a few more pertinent questions from the user. First, the site name, which is stored in the variable siteName. Then the directory name, which is... take a guess!

begin
    puts "What is this site called?"
    siteName = gets.chomp;

    puts "Please input the name of the new directory to be created."
    puts "If this is a subdirectory of another directory, the parent folder must exist."
    directoryName = gets.chomp;

    puts "Do you wish to continue? (Y/N)"
    continue = gets.chomp
end while continue == "Y" or continue == "y"

So far so good?

Here, we'll do a little test by checking if the directory pointed to by directoryName already exists. If it does, print an error message.

begin
    puts "What is this site called?"
    siteName = gets.chomp;

    puts "Please input the name of the new directory to be created."
    puts "If this is a subdirectory of another directory, the parent folder must exist."
    directoryName = gets.chomp;

    if File::directory?(directoryName)
        puts "This directory already exists."
    else

    end

    puts "Do you wish to continue? (Y/N)"
    continue = gets.chomp
end while continue == "Y" or continue == "y"

If not, use the mkdir() method of the Dir object to create the directory. And at the end of it, print a success message.

begin
    puts "What is this site called?"
    siteName = gets.chomp;

    puts "Please input the name of the new directory to be created."
    puts "If this is a subdirectory of another directory, the parent folder must exist."
    directoryName = gets.chomp;

    if File::directory?(directoryName)
        puts "This directory already exists."
    else
        Dir.mkdir(directoryName)

        puts "Site created for %s." % [siteName]
    end

    puts "Do you wish to continue? (Y/N)"
    continue = gets.chomp
end while continue == "Y" or continue == "y"

You'll see this happens. A folder is created. It's empty, but it's there. Just like my wallet. (hur hur)

But wait, what if you try this a second time? That's right, your program gives you an error message because you already created that directory.

Now, what if you try creating a subfolder in a folder that doesn't exist?

That's an excellent question, compadre, and I'm going to answer that right now. What happens is that Ruby throws an exception. But like any worthy programmer, we want to handle this exception.

We catch this exception by placing the rescue clause before the end of the While loop. Then we use ENOENT as the exception name (ENOENT pretty much stands for Error, No Entry which is the kind of exception thrown when a specified directory is not found), so if the  directory is not found, control passes on to the block after the rescue clause.

    puts "Do you wish to continue? (Y/N)"
    continue = gets.chomp

rescue Errno::ENOENT

end while continue == "Y" or continue == "y"

From here, we print an error message and resume asking if the user wants to continue.

    puts "Do you wish to continue? (Y/N)"
    continue = gets.chomp

rescue Errno::ENOENT
    puts "Error: Directory not created. The parent of the new directory '%s' was not found." % [directoryName]

    puts "Do you wish to continue? (Y/N)"
    continue = gets.chomp
end while continue == "Y" or continue == "y"

Yep, it works!

OK, we've tested and handled all possible points of failure. Now let's handle successful cases. If everything goes smoothly and the directory is created, what we want to do is create subdirectories and files within that directory. To do so, we'll use Ruby's Dir object. The chdir() method makes the program go into the directory specified. In this case, it's the newly created directory. From there, we use the mkdir() method to create the directories js, img and css within the new directory. Ever use FTP before? Pretty much the same thing!

    if File::directory?(directoryName)
        puts "This directory already exists."
    else
        Dir.mkdir(directoryName)

        Dir.chdir(directoryName)
        Dir.mkdir("js")
        Dir.mkdir("img")
        Dir.mkdir("css")

        puts "Site created for %s." % [siteName]
    end

You will need to test this by removing the webgentest directory previously created, but once you run your program again, you should see subdirectories within webgentest.

Now, we change directory to js, and inside the js folder, create a new file using the new() method of the File object. We'll call it script.js, though feel free to call it anything you like. The second argument is "w" for Write mode. It doesn't really matter at this point because...

    if File::directory?(directoryName)
        puts "This directory already exists."
    else
        Dir.mkdir(directoryName)

        Dir.chdir(directoryName)
        Dir.mkdir("js")
        Dir.mkdir("img")
        Dir.mkdir("css")

        Dir.chdir("js")
        jsFile = File.new("script.js", "w")

        puts "Site created for %s." % [siteName]
    end

...our next step is to close that file. Yep, we're not writing anything in it. It's blank. Now that this is done, use the chdir() method to move back to the webgentest directory.

    if File::directory?(directoryName)
        puts "This directory already exists."
    else
        Dir.mkdir(directoryName)

        Dir.chdir(directoryName)
        Dir.mkdir("js")
        Dir.mkdir("img")
        Dir.mkdir("css")

        Dir.chdir("js")
        jsFile = File.new("script.js", "w")
        jsFile.close
        Dir.chdir("../")   

        puts "Site created for %s." % [siteName]
    end

Do the same for the css subdirectory.

    if File::directory?(directoryName)
        puts "This directory already exists."
    else
        Dir.mkdir(directoryName)

        Dir.chdir(directoryName)
        Dir.mkdir("js")
        Dir.mkdir("img")
        Dir.mkdir("css")

        Dir.chdir("js")
        jsFile = File.new("script.js", "w")
        jsFile.close
        Dir.chdir("../")   
   
        Dir.chdir("css")
        cssFile = File.new("styles.css", "w")
        cssFile.close
        Dir.chdir("../")

        puts "Site created for %s." % [siteName]
    end

To test this, delete the webgentest directory and run your program again. Now in the js and css subdirectories, you should see the files you created.

Now, in the main directory, which is webgentest, we start creating the index file. This will be called index.html, and this time, we use Write mode for an actual reason.

        Dir.chdir("js")
        jsFile = File.new("script.js", "w")
        jsFile.close
        Dir.chdir("../")   
   
        Dir.chdir("css")
        cssFile = File.new("styles.css", "w")
        cssFile.close
        Dir.chdir("../")       

        indexFile = File.new("index.html", "w")
        indexFile.close

        puts "Site created for %s." % [siteName]

We'll use the syswrite() method to start writing lines within index.html. This is where we get to use siteName which we defined earlier as the title. script.js and styles.css are referenced in the head tag.

        Dir.chdir("js")
        jsFile = File.new("script.js", "w")
        jsFile.close
        Dir.chdir("../")   
   
        Dir.chdir("css")
        cssFile = File.new("styles.css", "w")
        cssFile.close
        Dir.chdir("../")       

        indexFile = File.new("index.html", "w")
        indexFile.syswrite("<!DOCTYPE html>\n")
        indexFile.syswrite("<html>\n")
        indexFile.syswrite("    <head>\n")
        indexFile.syswrite("        <title>" + siteName + "</title>\n")
        indexFile.syswrite("        <script src=\"js/script.js\"></script>\n")
        indexFile.syswrite("        <link rel=\"stylesheet\" type=\"text/css\" href=\"css/styles.css\">\n")
        indexFile.syswrite("    </head>\n")
        indexFile.syswrite("\n")
        indexFile.syswrite("    <body>\n")
        indexFile.syswrite("        <!-- Your content here -->\n")
        indexFile.syswrite("    </body>\n")
        indexFile.syswrite("</html>\n")
        indexFile.close

        puts "Site created for %s." % [siteName]

Time to test! Delete the webgentest directory one last time, then run your program. Now you should have index.html in your main directory.

And index.html will have this written in it!

Possible modifications

Now that we've done all this, you could modify this little generator to do things how you like them. Maybe you don't like the naming convention? Change it! Perhaps you'd like more stuff in your index.html file? Or maybe you don't even want an index.html file, but prefer index.php or index.asp? All doable. Sky's the limit, yo.

Ruby's a nice little language for the little pleasures in life. Of course, it's capable of far more powerful stuff, but this is a great start!

Thank you for reading. It's been a genuine pleasure!
T___T

Fiction Review: The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win

Around Christmas last year, the company gave us some recommended reading. Dutifully, I read it once to fulfill my professional obligations, and read it a second time to make sure I got the important bits. While I may have read it twice - which is probably two times more than most of my colleagues - claiming to thoroughly enjoy it would be a horrendous stretch of the truth.

The book is titled The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, and if ever there was a misleading title, this would be it. Not because the title is wrong - it is about something called The Phoenix Project - but because looking at the title made me think of spy adventures, car chases and fiery explosions. No such luck - this novel is dryer than a popcorn fart. Still, it is a tech novel. And after having spent all that time reading it (and as far as I'm concerned, that's a few hours of my life I ain't ever getting back), I figure I should at least be able to write a review on it.

This book is written by Gene Kim, Kevin Behr and George Spafford. If they ever write any more stuff that's not a work of fiction, I'd probably read it. Because nothing can be worse than their fiction... I hope.

The Premise

The protagonist is a Director of Midrange Technology Operations in a manufacturing and retail company, Parts Unlimited. One fateful day, he receives a promotion to the rank of VP of IT Operations and discovers that his troubles have just begun. Deadlines are looming for the floundering Phoenix Project, processes are a huge mess and the amount of politics he has to wade through is staggering. Along the way, he discovers the right way to do things, gets his colleagues on board, and turns the operation around, culminating in the success of The Phoenix Project.

We'll see a lot of references to manufacturing practices, and how automated DevOps come into play. It's really a case study disguised as fiction. If that's your poison, you'll love this novel.

The Characters

Bill Palmer, VP of IT Operations and the protagonist of this novel. He's in over his head much of the time, and since this novel is in first-person format, a lot of what we see is from the view of this guy.

Steve Masters, CEO. The head honcho at Parts Unlimited who starts off as the strangely charming boss who doesn't do well under pressure and tries to impose upon IT what his vision of IT is. I've worked for that sort; it rarely ends well. So it's bit of a surprise when he starts acting sensibly (and with a lot more humility) mid-novel.

Erik Reid, Board Member. Nondescript, chubby, old. Doesn't look like anybody important, until he opens his mouth and starts speaking in riddles. He's apparently the Yoda of the book, and dispenses advice, sometimes cryptically so. Even refers to Bill as "grasshopper" at some point.

Sarah Moulton, SVP of Retail Operations. The antagonist of the story. She's insecure and conniving, always plotting to score political points at somebody's expense. Unlike many of the other characters, there's no redemption for her at the end.

Wes Davis, Director of Distributed Technology Operations. Overweight, outspoken, and shoots from the hip.

Patty McKee, Director of IT Service Support. She's described by Bill as "thoughtful, analytical, and a stickler for processes and procedures". This earns her a fair amount of ire from people who just want to work. However, her fanatic focus turns out to be a boon as Bill and team frantically try to restore order.

Brent Geller, Lead Engineer. Guy doesn't have much of a personality, so it's a bit of a surprise that he's mentioned every few pages. Apparently he's a brilliant engineer who, as a resource, is misused by just about everyone.

Chris Allers, VP of Application Development. Physically fit, has a reputation as a capable and no-nonsense manager. Gets buddy-buddy with Bill midway.

John Pesche, Chief Information Security Officer. Mid-thirties, haggard, overweight. Officious and self-important, his pompous exterior hides a really insecure guy beneath. He starts off getting in the way of everyone due to inane security policy implementation, but by the end of the novel he's on board. Has the most amount of character growth among the entire cast.

Dick Landry, CFO. I kind of like this guy. He's so funny when he's stressed out. "Get your IT guys to fix this. The hole this blows in our quarterly numbers will be impossible to hide, and maybe even impossible to explain away. Call me, Steve. I’ll be on the window ledge." Hilarious.

Paige, Bill's wife. Doesn't have much to do in the novel other than remind the reader that Bill Palmer has a family.

The Mood

Bland and formulaic. You already know how it's going to end before you read it. It's that kind of book. It's here to teach you a few lessons, but first, it walks you through the horribly screwed up situations just so you know what happens when you don't do things right. And then it gives you a few hope spots here and there, but ultimately, it's really predictable.

What I liked

Lessons are imparted into the novel conveniently. The four types of work, the Three Ways, the comparisons of IT to manufacturing, value streams and so on. No, really. Without these, there's absolutely no reason for this novel to exist. The story fucking sucks! And anyone who can say otherwise with a straight face has either not read that many novels or is one hell of a poker player.

The yelling match between Steve and Bill. Just when the novel was starting to put me to sleep, this little fantasy of telling my boss off and tendering my resignation with more drama than necessary, gave me a proper jolt. In practice, of course, real professionals quit as quietly as possible. The quieter the better.

This part was actually pretty funny.

Show me a developer who isn't crashing production systems, and I'll show you one who can't fog a mirror. Or more likely, is on vacation.

Character development. Whatever else you might say about the characters, at least some of them go through a transformation. To me, they're either boring as heck, one-dimensional or annoying... but at least they aren't static. That's something.

Bringing back bad memories. Being a techie and having work dumped on you by know-nothings who are convinced that their work is so important that this makes them exempt to the rules put in place for due process? I've worked in companies like that before. This is way too relatable. I give this novel mad props for that.

What I didn't

The entire Yoda shtick with Erik Reid. Seriously, his entire persona was probably supposed to sound cool, but reeks of bombast and pretension. What's with the habit of deliberately failing to get everyone's name right until they prove to him they're worthy of that basic courtesy? What a dick.

The way Bill finds out what the four categories of work are. In this day and age, couldn't he just do a goddamn Google search? I guess it wouldn't make for such a nice story though...

Kirsten Fingle, who runs the Project Management Office. Nancy Mailer, Chief Audit Executive. Maggie Lee, Senior Director of Retail. Laura Beck, HR. Stacy, Steve's PA. You know what? They all sort of start to blend together at some point. There's really nothing about any of these people that make them stand out as individuals. The authors probably don't spend a lot of time around professional women.

Weepy touchy-feely sappy session where Steve gets everyone to talk about their goals and aspirations and be vulnerable in front of everyone else. God, that was painful to read. Can y'all just get back to hating each other, please?

Bill was from the Marines. So was Erik. And Steve was from the military or something. What is it with the authors and ex-military personnel? Are they implying that only people who have gone through military training can do this shit? Absurd.

Generally, I don't get this novel. I just don't understand why something like this exists at all. What did it accomplish that a series of case studies couldn't? The authors are probably brilliant VPs, Managers and Directors... but they aren't novelists, that's for sure.

Conclusion

If you're not a techie, this book may not be for you. Heck, even if you are a techie, trying to stay interested in the story is a struggle unless you really like reading about office politics and the day-to-day grind of IT operations. In a friggin' novel.

This is just my opinion, though. It's supposedly gotten rave reviews from techies all over the world and Management in my company seem to love it, so it must be doing something right. Maybe I'm off-base here judging it on the basis of (gasp!) storyline and (double gasp!) characterization. But what the hell, man. I'm not Management and I'm under absolutely no obligation to even pretend to like it.

My Rating

4.5 / 10

The Phoenix Project just doesn't fly.
T___T

Why I don't call myself a Full-stack Developer

During some leisurely exploration of job sites, I came across an interesting trend. It seems there's an increase in companies requiring a "full-stack" web developer. For (gasp!) 3000 to 4000 SGD a month.

I have to wonder - do people even realize what they're asking for? Why "full stack"? The typical answer would be, as long as you've worked on two layers (namely, the front-end and the back-end), you're a full-stack developer. I strenuously disagree.

What does "full-stack" really mean?

In order to explain that, I would first have to begin with explaining the anatomy of a web development process. There are several layers of technology stacked (hence the term "full-stack") on top of each other. These may include, but are by no means limited to:

- Hosting/server/network
- Data Modelling/Systems Analysis
- Back-end programming/APIs
- Front-end design/HTML/CSS/JavaScript
- Marketing/SEO
- Project Management

Or to make things even simpler, what does the "stack" in "full-stack" actually refer to? Here's an example. Ever heard of LAMP?

No, not that lamp.

LAMP is a technological stack. It's an acronym comprising of all the technologies that make up its layers.

L is for Linux, which is the operating system.
A is for Apache, which is the server.
M is for MySQL, which is the database.
P is for PHP, which is the application scripting language.

And bear in mind that this is a much simpler example than the first. For this simplified example, a full-stack dev would need to be intimately familiar with only four layers. That's still double the number of layers most laypeople associate the term "full-stack" with.

A full-stack web developer has a good understanding of each layer and has attained a respectable degree of proficiency, if not mastery, over them. He has experienced web development in all these areas. He is the total package and can code your entire web application for you. All by his lonesome.

So, the question that remains in my mind is...

...why would such an awesomely multi-talented and experienced web wizard want to work for you for 3000 to 4000 SGD a month?

Oops, was I perhaps a little too honest there? But seriously, do these guys know what they're asking for when they say they want a "full-stack" web developer?

Football analogy

For those of us who watch football, here's an analogy.

The modern game has evolved. In the past, there was a goalkeeper, defenders, midfielders and strikers. Each specialized in their own area. Now, strikers have to backtrack to help out in defence. Defenders are expected to make the occasional foray up front. And midfielders - sorry guys - have to be everywhere. They have to provide assists, take shots, make tackles, link up with both defence and attack... yep, a lot of cross-training involved.

Let's talk football.

However, everyone is still a specialist. They may excel in more than one area, they may have to take on multiple roles on the pitch, but rare is the footballer who can be deployed anywhere on the field without thoroughly fucking up your game plan. No manager in his right mind is going to place Lionel Messi in defence, Sergio Ramos as central striker, or David Villa in goal.

Did that make sense, or did I just convince you that I know as little about football as I do about web development?

That said, David Villa could still make it as a goalkeeper. If the team in question was your typical High School first eleven. Because the bar for that would be significantly lower.

In other words, if you just need a generalist web developer for a relatively simple set-up to take care of all layers of the development process, fair enough. And if a small company or startup thinks they want to cut headcount by hiring a jack-of-all-trades, hey, I'm not about to judge.

But in this day and age, each layer of technology in the web development stack has grown. And is still growing. Is it realistic to expect anyone to be "full stack"? Web developers need to cross-train in several disciplines. They can't just get by with knowing only one layer of the entire process. At the very least, an understanding of how the current layer you are working with interacts with the next adjacent layer, or layers, is required.

So if a hiring company just wants cheap labor to take care of everything, here's a startling concept - just be honest about it. Stop abusing the term "full-stack".

Here's your stack, right there.

Because when we say "full-stack", we're talking about someone who has gone elbows-deep into each layer of the web development process. He's not just gotten his feet wet. Not just someone who has an interest in every layer and has poked around a bit, and knows how to throw fancy words like "Agile", "Scrum", "methodology" (and "full-stack", for that matter) around to sound like he knows his shit.

Speaking of which...

There are plenty of web developers who claim to be "full-stack" because they've done both front-end and back-end work. By that measure, almost all web developers are "full-stack". Have you ever met a front-end specialist who hasn't had to write back-end code and SQL queries? Do you know any back-end engineers who can't write a single line of HTML? I seriously doubt it.

Stop doing that. It's embarrassing to watch. We get it, you want to sound special. Stand out from the crowd.

But "has done both front-end and back-end work" is a requirement set by recruiters whose job is to sell candidates to companies, and claiming that their candidate is "full-stack" brings up the perceived value. I'm not going to be so crass as to claim that every recruiter knows diddly-squat, but more often than not, they are laypeople in the tech sector. Those are their standards. As a developer, you should be holding yourself to higher standards.

Calling someone like me a "full-stack developer" just because I've been employed by companies that made me do everything in the web development assembly line, is an insult to the real experts.

See you layer, alligator.
T___T

Five Comparisons Between Contract and Permanent Roles

There was a time I harbored a deeply-rooted prejudice against contract positions. I saw them as second-class at best, expendable at worst. What self-respecting developer, I thought, would allow himself to take up a contract position? A decade later, I would be disabused of this ill-informed notion. A year or so in a contract position, coupled with several tempestuous years in permanent positions, has taught me differently. There are differences, of course, but these differences are neither good or bad; it all depends on the context.

1. Job Stability

There's this myth going around that contract positions are inherently less stable than permanent roles. That's true on the surface, but being professionals and all, let's try to look deeper.

Unstable?

The typical contract's duration runs from six months to a year. During this time, while theoretically the company reserves the right to terminate employment at any time, most employers are notably reluctant to do so without good cause. ("Good cause", in this case, means a serious breach of professional ethics or extreme negligence, which is grounds for immediate termination regardless of whether you're a contractor or permanent staff.) Thus, if they think you're underperforming and want to get rid of you, all they need to do is wait out your contract's duration and at its conclusion, inform you that it will not be renewed. However, there is no such option in the case of permanent employees. Therefore, the only other recourse is to fire you, or make your position so untenable that you voluntarily resign.

Job stability? Job security? It's all an illusion. The only job security you can realistically have is what you make for yourself. If you understand and have what your industry needs, it won't matter if you're employed; you'll be able to get out there and land a job just like that. That's security. Anything else is bullshit.

Also, consider this. The typical software project is transient in nature. It runs for an allotted time, and once it's done, the company needs to find work for the permanent staff member in order to justify his stay. For the contractor, there is no such problem. He simply sticks around for maintenance until his contract is up, and then he leaves. No fuss, no muss! At an interview, hiring Managers get suspicious if they see that the applicant has not been in any company more than a couple years. They will ask no such questions of the contractor because they understand that this is the nature of contracts, i.e, they run out when the project is completed.

2. Career Progression

As a contractor, you are outside of the company's corporate structure. Therefore, there is no meaningful way to promote you. The best you could hope for would be some unofficially senior status.

That's true enough, no argument there. Where I differ from many people is whether or not that is a bad thing.

You're not part of this game.

You see, the entire point is about being outside the company's corporate structure. This basically means that you're probably going to be excluded from all the office politics going on within the corporate structure. That's because, being a contractor, you're not a pawn. Hell, you're not even on the chessboard!

I've been in a permanent role before, where my colleague took every opportunity to upstage me and look good at my expense. That was because she needed to look good to the higher-ups. There was a vacancy in Management and she wanted that promotion. (Spoiler: She did get promoted. I don't think she enjoyed it much.) Years later, I am a contractor surrounded by other contractors. None of us waste time with silly games of one-upmanship. I don't have to be afraid of being stabbed in the back or of people scoring cheap political points off me. Because there's no promotion up for grabs, or even a possibility for conversion to permanent status. We are all contractors and we will remain contractors no matter how good we look. There is nothing to gain.

Besides, just because you don't get a fancy job title and a huge paycheck, does not mean that there is no career progress. I'll expand on this point another day, but career progress in tech should be measured by the value of the work you produce.  Anyone clueless enough to measure your career progress by what's printed on your business card, probably doesn't have anything meaningful to add to the conversation.

3. Benefits

Contractors don't get as many benefits as permanent staff. On the flip side, they do generally get paid more, since these benefits cost the company money, money that the company does not have to spend on the contractor. Again, whether or not that is a good thing depends largely on what you need.

More vacation days.

More annual leave? What would I do with it? I spent most of my time in the swimming pool or library anyway.

More sick days? You're talking to a guy who once went a stretch of eight years without needing to take a single sick day.

Insurance? What, you don't have your own insurance policy and need the company's coverage? Something's not right here.

Training? You actually depend on your company to provide you with training? What is wrong with you?!

Bonuses? Here's a sobering fact, my friend: ever since the Singapore Government mandated that the annual bonus is entirely at the company's discretion, several SMEs, all at the same time or thereabouts, declared themselves too cash-strapped to pay bonuses. Annual bonuses either shrunk drastically or outright disappeared. And in many cases, they never came back.

Also, there's the question of how much one really needs a year-end bonus.

Sure, a sum of money at the end of the work year is nice to have. But I don't need it. Without it, I'm not going to starve or even be mildly inconvenienced. I barely spend a quarter of what I make, and at the end of the year there's always enough money for Christmas treats for the family and insurance payments. You know about monthly bills? Those things that arrive in your mailbox more regularly than the typical menstrual cycle? There's an awfully good reason why they're called "monthly bills" - they arrive monthly. Not once a year. If you live your life in such a way that you're held hostage by the availability of a year-end bonus, the problem is not the bonus.

Besides, I've worked for companies in a permanent role, where I got ten days of annual leave a year and no bonus. To hell with the supposed benefits for permanent staff. Just give me my contractor pay.

4. Prestige

The common perception is that contractors are contractors only because they're not good enough to be permanent staff. I can see why people would think that way- I used to, once!

The bar isn't lowered.

However, the entry requirements for permanent staff remain the same for contractors. Contract positions are not some kind of consolation prize for failing to land a permanent role. The bar doesn't get lowered for contract positions. If you're not good enough for a permanent role, you won't be good enough for contract work either. (Let's not talk about companies that put people in contract roles with the promise of a conversion to permanent status if they perform well enough. Those are tactics by desperate employers, meant for desperate employees. Pro tip: Don't be desperate.)

The fact is that contractors will be exposed to several different technological stacks due to working in different companies and different projects. That could be an enormous advantage, depending on who's hiring. The permanent staff member has no such luck; he has to stick around and work on the same technological stack for years - and if that ever gets deprecated, he's utterly screwed.

Also, major tech companies like Facebook and Google now have contractors as the majority of their workforce. That's the way the industry is swinging, and that reality is reflected in the way hiring Managers look at your resume. Contract positions are now an accepted norm rather than the exception.

At the end of the day, the company you're in matters more than whether it's a contract or permanent position. Being a contractor in a tech giant like IBM, for example, is objectively better for your resume than being permanent staff in some tiny, no-name operation.

5. Administration

Typically, a contractor needs to fill in and submit timesheets in order to get paid. That's annoying as all heck - any developer worth his salt would much rather be writing code - but I guess you could get used to it eventually. I know, after everything I've said so far, this is a minor inconvenience, at best.

That damn timesheet.

Still, compare it to the sheer pleasantness of having your bank balance credited without having to lift a finger if you're in a permanent role.

Conclusion

Would I take up another contract position? Yes, in a heartbeat.

Sure, all things being equal, I'd still choose a permanent position over a contract. Because I'm getting a bit too old to be running around job-hunting every couple years . But my disdain towards contract positions has all but melted away. I've come to see that contract positions hold a certain niche in the tech landscape, and it isn't going away anytime soon; rather, it looks to be growing. A tech professional could still ignore this option, of course... but keep an open mind. The day may come where a contract position looks like an attractive course of action. If you're ten to twenty years younger than me, you might want to give it a shot. What have you got to lose? You're early in your career, you're still making up your mind and finding your feet... may as well make it look legit.

As with all things, ignore what others have and stop being obsessed with "not losing out". Context matters. Consider your own needs and working style instead, and then decide what suits you, not other people, best.

Take up a contract. Expand your world. (heh heh)
T___T

Women Can Code, Get Used To It (Part 2/2)

Sometimes guys in tech don't handle the presence of women well. They appear to take it as a challenge to their dominance or some crap like that. Their reactions seem to pretty much stem from resentment. "She's hot, sexy and she can code, perhaps even better than me. It's not fair!" Again, developers are people. People come in all shapes and sizes. Thus, developers come in all shapes and sizes. Leave your Prototype Bias behind.

Yes, that could be
a programmer. So what?

Also, who said life was fair in the first place? A female developer can have big boobs, look way hotter than you, get laid more often than you and code better than you. Suck it up, buttercup!

But it's true! Women just aren't as good as men at tech...

Buddy, let me stop you right there. There are plenty of perfectly good hills to die on, so you might want to give this one a pass.

I'm not part of any kind of feminist movement, or some wannabe white knight. I am a software developer, and while I may not be a master of my craft, I understand the history of my own industry enough to say this: women can code; it's an objective fact.

Did you know that the first ever computer algorithm was written by a woman? I shit you not; there's even a programming language named after her.

When's the last time you used an ATM? 95% of these worldwide are still powered by COBOL. Guess who was largely responsible for COBOL's development roughly six decades ago? That's right - a woman. Rear Admiral Grace Hopper, to be exact.

And before the above-mentioned woman asserted her belief that code should be written in something close to English (like all the fancy programming languages you and I use today), people were still dealing with machine language and assembly. Guess what the vast majority of them were? Yep - friggin' women.

So yeah, let's have no more rubbish about how women can't code, OK?

Programming is about logic. And women are creatures of emotion, not logic...

Seriously, arguments like these are not helpful. So are people claiming that women are more detail-oriented and intuitive, and more suited than men for task x and job y. If you're going around saying things like that, you may think you're complimenting women, but in reality you're part of the problem.

Even if it's true that women are more x and men are more y, nobody with any ounce of professional pride wants to compete in terms of gender. If we start hiring based on gender (women for QA and men for programming or whatnot), a great deal of talent will remain untapped. And in a world where the demand for tech talent far outstrips the supply, this is not a good thing.

But there are more men than women in Silicon Valley!

Yes, that's true. Men outnumber women by a ratio of maybe five to one. But understand this - capability has nothing to do with it. Programming isn't some rocket science reserved for the intellectually endowed, though as with all disciplines that require logic and thinking, a high I.Q can't hurt.

Programming?! Ew, no.

No, software development is as much about temperament as it is about anything else. Not everyone wants to code for a living. It takes a certain kind of personality to want to do this professionally. And, for some reason or other, women seem to want the life of a software developer less than men.

Not just men

Sadly enough, that bias is not restricted to men. Women, too, subscribe to the stereotype that other women generally aren't as technically gifted as men. Take this conversation I had with a friend a couple years back.

Her: ...so my colleague developed a whole suite of applications using Excel macros. She learned it all by herself, did her research on the Internet and everything.

Me: Mmm. OK.

Her: She's a girl.

She listed the accomplishments of the colleague above, and when I did not appear impressed enough, tried to compound it with an added accolade - "she's a girl". Now, that's pretty insulting. I understand that my friend didn't mean to be derogatory, and she was genuine in her admiration. However, compliments like these do more harm than good.

Achievements are praiseworthy on their own. Achievements don't magically become extra deserving of praise simply because they were done by "a girl". That is like saying women, by default, are inferior to men, and therefore if they achieve anything, their achievement deserves more admiration. That's sexist and counter-productive. Not to mention condescending!

Conclusion

That's why we shouldn't glorify women in tech. Glorification of the idea that women can code, is giving credence to the Prototype Bias that women can't. I get it, people who do this have (probably) good intentions and are trying to help. But no, they're really not helping.

Because there is nothing to glorify. Women can code. They've been able to code even before I was born, and somehow people seem to have forgotten that when they get all excited over it like it's some new and special phenomenon.

It's not supposed to be special. It's supposed to be normal. It shouldn't be a big deal because it isn't. All of us - men and women - need to stop thinking of tech as a male or female profession. It's a profession, period.

Time to man up, developers!
T___T

Women Can Code, Get Used To It (Part 1/2)

This summary is not available. Please click here to view the post.

An Extraordinary Day in the Life of an Ordinary Developer

Remember when I wrote about good and bad days at work? Just a week ago, I had an extraordinarily good day.

It was evening in the office. I had been feverishly debugging a deployment process tasked to me, for the past couple days. To no avail - the tasks ran smoothly and everything seemed correct, but the web application simply refused to run. I could get into the login screen, but an error message was displayed every time I tried to log in. And nothing in the logs was giving me any clues, at least, nothing I could search StackOverflow for.

I was stuck. Boy, was I totally stumped, mystified and pissed off. Hours had passed since morning, with me trying every configuration option possible. DevOps wasn't my thing, but it had been tasked to me and I had to get that done, no two ways about it. Just about everyone had left for the day. I sat there stewing quietly in frustration, and wondering what else I could possibly do.

And then it hit me. I was barking up the wrong fucking tree. Hell, I was in the wrong fucking forest to begin with.

Wrong forest.

I could access the login screen, which meant files and the base URL were just fine. But if I was failing on login, that was probably to do with the database, because the data had to be verified there. And if there were no logs, that was a clue in itself. It meant I wasn't even connecting to the damn thing. With that in mind, I examined the config file for the culprit, this time with a renewed sense of purpose. And when I scrolled to that line where the connection string was, that's when I saw it. One digit was off in the port number. One. Goddamn. Digit.

I changed the value, and ran the test again. And when the dashboard came up after logging in, indicating that I had successfully squashed that bug, that intense triumph I felt gave new meaning to the term "better than sex".

That high remained with me all the way home, as I rode the train with that silly grin on my face. It felt so special that I'm writing a blogpost about it.

But it's not just about me being oh-so-brilliant. In the hands of a more experienced, more able developer, that bug would have been squashed long ago. There was otherwise nothing remarkable about this incident.

And that is precisely the point.

It's moments like these that reaffirm the choice I made a full ten years ago, when I quit my desktop support job and ventured into the murky world of web development. Ten years later, the unbridled enthusiasm remains, the same eagerness that first saw me through several setbacks over that decade. That's remarkable. Skill can be taught. Enthusiasm can't. More skilled devs than myself have burned out and decided to call it a day. Because being a techie, like many other professions, is about a lot more than skill. It is about who you are when all the programming know-how, fancy frameworks and whatnot have been stripped away.

The fact that I could feel so unreasonably pleased with the evening's work, even for so negligible an accomplishment; the sheer amount of pleasure I wrung out of that magical moment where more jaded developers would have simply glossed over, is indicative. I was made to do this job.

Cold water

And then there are the party poopers. They'll be the ones who choose to harp on the fact that I stayed back two hours past official knock-off time. They will tell me that what I do only benefits the company at my expense.

I refuse to fall into the trap of thinking that way. That is small-mindedness, and small-minded people, generally, don't accomplish greater things. I've said it before - work is not simply work. Work is also training yourself for your next job. I put in the extra time not because I want to impress anyone (most of the time, nobody even knows) but because I want to train myself. The fact that the company benefits, is merely a side effect.

Back when I was still actively performing Reservist duty, I had the opportunity to speak to some of my fellow reservists. This guy in particular was griping about how cheaper foreigners are replacing us at our jobs and how our Government isn't doing anything to stop it. I told him a story of how I'd replaced three Indian nationals simply by doing all their jobs. My purpose wasn't to brag - well OK, maybe a little - but my main point was that it's how we adapt to the environment that matters. It's our attitude towards our profession that counts.

His response was a sneer. "So you're reduced to doing three jobs for the price of one. See? Too many foreigners."

Always unhappy.

I was left speechless. Technically, he was correct. But that wasn't the point at all. Sure, I was doing the work of three people, but it was still less work than I was accustomed to and for more money. It occurred to me then, that some people are bitter and unhappy, and determined to stay that way. There's absolutely nothing I can do for them. They will compare what they have constantly to what others have, forever coming up short, instead of appreciating what they do have or making the best of situations they cannot control. If they do extra work, they will think of it only as (grudgingly) giving the company a freebie, never in terms of their own benefit.

Also, more disturbingly, this guy was an officer. A leader of man. Cream of the crop. At some point in the Republic of Singapore Navy, he was probably one of the brightest and the best, and probably gave the extra mile to even get into Officer Cadet School. What happened to that drive? Life get him down? I'll never know. But it's very sad.

Work-life Balance

People like to talk about this. I think they talk about this way too much. It's become one of those douchebaggy buzzwords of the new millennium.

I used to say "I don't have a work-life balance. I have a work-work balance.", in obvious reference to the fact that I code just as much outside of work. Like all the other people who overuse the term "work-life balance", I was naive and didn't see past the obvious fallacy.

Always tinkering.

You don't magically become someone else from nine to five, then revert after that. You're still you. I'm still a software dev even in the comfort of home, even when I'm not doing any work from the office. I approach problems in much the same way, and I like to find out how something works rather than simply what it does. In many ways, I'm still the same excited teenager who discovered C++, HTML and JavaScript in 1996.

Hence, there is no such thing as work-life balance. At least, not the way people understand it. It is all life. Work is part of life. And if, for some reason, you really are someone else on and off the pitch, you probably don't like your job very much. You have my sympathy. It's a terrible position to be in, to spend almost a third of your life doing something you don't care for.

I'm blessed to be earning good money in a field I care about, even though I'm probably crap at it. And I never forget it.

Your very ordinary developer,
T___T