How I Start The Morning
- Grab my favorite coffee, quad tall one Splenda latte from Starbucks.
- Sit down on my desk and turn my computer on.
- Login and open my terminal
- cd box/{name of the project}
- git pull
- open iTerm or another terminal tab
- tun (my alias for creating tunnel to my home server
- open Adium or Pidgin
- open another terminal tab
- gem server
- open my secondary browser
- http://localhost:8808
- open my email client
- start my work
So, how’s your day?
Why Ruby & Rails Needs Enterprise and Regulations
During the Pragmatic Studio I attended, a subject came up where I voiced concern over the fact that Ruby allows the programmer to override behaviors of “core” components. Dave Thomas explained that the other language designers assume that people are idiots and that’s why they put all the constraints. Although I disagree, I do love the fact that Ruby gives me a great deal of power.
I fell in love with Rails when I saw that Rails lowers the barrier to entry in web application development. What I didn’t realize at the time was that when you put out goodies in the wild, you tend to attract lots of wild animals. I’m finding out that convention over configuration can be abused to a point where I’m constantly trying to look for convention that once existed since Ruby allows you to smash convention.
I’m now accepting the fact that I’ll always be hired to solve problems. That means just about all my projects will be unscalable, full of technical debt, and design dead codes. Considering how young the language and the framework is, I find it somewhat shocking that so many projects are design dead at such early stage.
Now that I think about it, Rails is popular among startups where they have to constantly put up screens to impress investors and change business model. I accept that this is the nature of the beast. Until the time when Rails is used for any enterprise system or any app that is under regulatory constraints, this will remain to be the fact.
Let’s face it, putting out well-tested quality code requires lot more time and effort than just throwing shit on the wall and see what sticks. We all give lip services to TDD or BDD, but when you have a deadline to an investor who wants to see something moving next couple of hours will not allow you to dick around with the quality. Something always gives.
Is this only limited to startups? Absolutely not! However, it is more likely that any enterprise system will be better planned and properly resourced. Sun spent ton of money to get people to follow standards because I remember in early days of Java when this was happening as well.
So, next time you hear a young Railer trashing “enterprise”, please tell him to stop.
Struggling With Testing?
We all know that we need to test our code since we don’t have a compiler in Ruby world. The issue that I come across is NOT how to write the tests, but what to test and how it should be approached. If you think about it, we have plenty of resources on the syntax and the mechanism of testing frameworks, but it ultimately comes down to what your testing strategy is, if there’s any.
I for one, do not subscribe to “test everything” bullshit some Rubyists are pushing. I get annoyed whenever I see tests that do not have any value whatsoever and are completely redundant. I know this will raise uproar but it’s true. When you see it, you’ll know what I’m talking about.
My tip if you’re struggling with testing is to read OPC. With the GitHub, all you have to do is point your browser to test/spec directory in any project. You’ll see both good, bad, and ugly. Form your own strategy based on your exposure, and remember, this is NOT religion! The ultimate goal of this whole thing is to write quality code. As I said before, all is not lost by looking at bad codes.
Hope this helps.
Are Down With OPC?
Other People’s Code, or OPC as I’d like to call since I am a child of the 80’s, is defined by me as crappy code. Of course I was joking to some extent, but I believe it’s something we need to address.
I always hear about learning to writing good code, but hardly ever hear about learning to READ the code, both good and bad. I was so happy when my fellow teachmetocode.com expert Chuck interviewed JEG (that sounds so much cooler than James Edward Gray III) in his podcast where JEG spoke about reading OPC. If you haven’t checked out his podcast, please do it NOW by going to http://www.railscoach.com.
As a software architect, I read lots and lots of code. I saw some excellent code as well as what can only be described as something only the mother would love.
You see, the code is same as any writing. It tells you what the code is trying to achieve and tells a story. I would compare it to any other fine literature or a junk novel. It has personality and style. It also tells the story of what was happening at the time of writing. For example, when I see that unit tests are missing when the rest of code base isn’t, it’s a sign of something being pushed out in a hurry.
Having said all that, I’d like to share my method for reading code. The most of this will be “duh, no kidding”, but I think it’s a good refresher.
- Before sitting down to read the code, I get an understanding of the final outcome.
- Understand the convention, design pattern(s), and the opinion of the framework.
- Have the language reference, API docs, and any other reference material
- Identify the entry point. I came from C, leave me alone!
- Identify the prerequisites.
- Start reading
- As I read, try to put myself in the same shoes as the person writing the code. e.g. what is his thought patterns, why did he do this way, is this guy a beginner or expert, is he trying to say “fuck you” to anyone reading the code, why is he writing Java code in Ruby, and etc.
- Follow the steps and write them down on a writing pad
- Absorb and appreciate, even if I think it’s a pile of crap
Next time, I may actually create a screencast going over a code review if I can find the time. Let me know.
1+1
1+1 shouldn’t be 1 1/2. However, usually this is what happens in terms of developer output. People expect 2, but that never happens, unless, there’s a proper management controls along with the right leadership that can produce 3 and increase exponentially as you add developers. I learned this from my early years when I had to work with extremely limited resources and budget.
People think it’s all about code. That’s true to a certain degree, but a company and the technology development is mostly about people. My recent startup-hopping showed me that too many people don’t get this.
Do you have 1+1 problem? Give me a call.
Happy New Year!
I’d just like to wish everyone Happy New Year!
I have to say that the year 2009 hasn’t been the best year of my life, and I’m really looking forward to 2010. I plan on generating more screencasts, write more tutorials, and finally contribute to an open source project.
Modern Day Sweatshop
Below describes the working conditions of a sweatshop according to Wikipedia.
“crowded, dangerous, low-paying, and without job security…”
I’d also like to add long hours and shitty benefits to this list.
Sounds familiar?
It should. I’m finding out that this is the working conditions of many developers. Yet, we take it like there’s nothing wrong with it. Why?
First of all, we’ve been brain-washed by the success stories of successful tech entrepreneurs bragging about working under these conditions. I don’t think I ever heard any of them actually talking about having a balanced life. If you really think about it, aren’t these people also the employers of developers? Do you think they have a financial incentive?
Another great bullshit I’ve heard is that developers get paid lot more than others. Well, if you take the amount and divide by the hours we’re forced to work, then you’ll know that we’re actually making less than others. I’ve also heard some grumble about consultant’s hourly rate. Well, if you think about it, there’s no sick days nor vacation days. How about the cost of health insurance and other overheads? I know, I did the calculations.
You must be thinking that I’m describing the working environment at a start-up. Not so. For some stupid reasons, people at well-established companies also think that they can treat “techies” like crap. It’s fascinating that we’re de-humanized, and therefore we don’t have human needs.
This has to change and it has to start from the top.
One thing I’m really proud is that when I was a CTO, I did not run a sweatshop operation. I made sure the working environment is a friendly one and made sure people are treated with dignity. I made sure they’re not overworked and always available for their family. Sure, there were times where we had to work crazy hours for few days, but they were far and few in between. I also made sure that a death march is a shameful event. It means we didn’t do a great job of planning and it’s a total collapse of expectation management.
So, next time you hear a developer bragging about how much he works, tell him that he’s working at a modern day sweatshop and should really shut the fuck up.
6-Mo of Full-Time Consulting
Today marks six months of me going full-time on my own. It’s been both exciting, disappointing, fun, hard, tiring, and most of all, extremely educational. Although not a complete list, I thought I’d share some important things I learned.
Getting Paid
Before you sign anything, make sure you have a payment schedule from your client and it’s same as stated in the contract. I made this mistake with a firm that handles the payment for the client I work for. Although I was given a payment schedule, the firm decided not to honor that and went with net 30 term. That effectively screwed up my budget and it’s not pleasant explaining that to my wife.
As for the payment term, if you invoice after two weeks and the payment term is net 30, you have to expect that there will be minimum of 6 weeks of non-payment when you go on your own. That is, if they don’t give you “the check is in the mail” line. Make sure you get a retainer upfront and check the credit of the company you’ll be receiving the payment from.
My advise here is that if you’re faced with working with a consulting firm and not the client directly, don’t do it. It’s much easier to talk to the people you work with than some outside company. I also saw this happen to other consultants when I worked with a consulting firm as a CTO.
Work Load
Don’t ever take on more work than you can handle. You’ll always get tempted by the financial reward but there’s more to life than money. I originally went into consulting because I thought I’ll get to see my family more. However, I ended up working like I did before. Always think about why you’re doing this to begin with.
I had to reduce the work load by transferring some clients to others who I trust. That’s another thing, always make sure your client that you can’t handle to good hands.
Time Management
As a consultant, time is money. I don’t have to explain how important time management is. Stay away from anything that is not considered productive use of your time. e.g. going out for drinking.
I have a gig that requires me to be onsite. What that means is that I have almost 4 hours of non-billable time per day. If you’re going to take on an assignment that requires you to be onsite, make sure your rate can cover that lost time. I use my commute time to catch up on studies and work online using EVDO.
Knowing My Place
Although I can offer lot more than what’s on the agreement, I have to be sensitive to the client’s employees and the management. The last time I opened my mouth and said what I thought, I ended up becoming a CTO. However, I did it because the person I was saying it to can handle it and was okay to do so based on the conditions at the time.
It used to frustrate me when I saw people making the same mistakes I made years ago. However, I now accept my role and there’s some comfort in knowing that they too, will learn from the mistakes. It may not always be the best thing for me to help. However, I’ll always roll up my sleeves if asked.
My Fellow Dorks at RB
Scary Trend – Charging for Service Packs
Sorry, I wasn’t one of those jumping up and down when they announced Snow Leopard and its “low” price. In fact, I’m disturbed by the fact that software companies are beginning to charge for service packs.
When I opened up ScreenFlow to record my next short screencast, I was unpleasantly greeted with an upgrade notice that says I now have to pay $29 for what appears to be a service pack. I find this insulting even as a person who makes living writing software. All I can say about this is that Telestream, the company that makes ScreenFlow, just lost a customer.
I live by a simple rule, treat everyone like the way you want to be treated, and if that’s not the case, well, do my part in punishing them.
