Jason Torres

Just a background, I’ve been mentoring people lately. The last part of my email somehow strikes me and it’s too cool not to share.

Pasting a snippet from my email:

Oh one last thing, one of the most important aspect of programming isn’t really learning how to program or code. While learning to code is relevant, there is a higher element which fuels it, that is having that strong hacker character because it will naturally strive and emanate good code which in return produce good results. We’re artists man.

http://www.reddit.com/r/ruby/comments/nwaz5/activerecord_and_rails_considered_harmful/

http://blog.steveklabnik.com/posts/2011-12-30-active-record-considered-harmful

Sounds like a post from somebody who’ve outgrown rails, which the bottom-line and natural thing to do next is, demand more or find an alternative or improve. Hopefully whatever that is, it’s for the good. Btw, webmachine looks good though ;). 

I disagree that Rails isn’t a good platform (for programmers). If you really think about it, it actually prevents you from doing bad decisions if you follow conventions. A.k.a “convention over configuration”. The code is open, you can peek anytime to see what’s happening behind in plain ruby. If a coder doesn’t know how to open the source, then that’s issue. I think it’s using magic without knowing the underlying concept or principle how it was done is more harmful. http protocol anyone?

The Rails’ conventions isn’t good enough just like what the guy is saying on his post, and I guess you have to respect that. But I do think it’s good enough and is serving it’s purpose. For somebody to understand, you might have to go back on its history. Rails was created on the dark days of building web apps, and it was really awesome when it came out if you were coding pre-rails era. Would you go back start manually coding forms, sql queries, post/get handlers, helpers, secure your code, again and again again? I don’t think so - in business sense it’ll be costly, security risk, harmful :p

Maybe, the world have outgrown Rails already. 

Lastly, There is a disconnect between “developer happiness and efficiency” Vs “This is the RIGHT way to do it”. You can’t have both apparently. Rails solves the former while still catching up with the latter. If you’re inclined with the latter, Rails isn’t for you, either go deeper, like rack? and I’m interested how far somebody can write using a bare rack application.

“Matz write C so we don’t have to”, hats off to the rails core team on doing the same for us rails developers.

I might sound pro-rails but I’m not 100%, it’s just in real-world situations, I find ruby/rails a very good solution to get something out quickly.

Or Why lousy tasks shouldn’t be assigned to programmers who got better things to do.

To give you an analogy, You hired a Lawyer and you’re paying him $500/hr. Obviously, you know it’s going to cost you a lot of money. So you’ll make the most of per hour that he is working. (unfortunately Lawyers just surprises you with their bill no matter how strict you are on it). And you tend to be smart about your decisions, you’ll just hire cheap researchers or even do some things yourself so you save a lot of money. Correct? Yes! Unless you’re rich (then you can close the browser and move on).

Another analogy, let’s say volunteerism, like cleaning the beach, you’re a lawyer that gets paid $1000/hr by doing overtime, and but instead of taking that 2 hour overtime; You just went to the beach and picked up garbages and cleaned the beach yourself. You enjoyed it being physically there, great! But imagine this, if you took the overtime, you had $2000/hr extra on your pocket, then rather than going to the beach, you just hire people that’s willing to do it at $10/hr (or just perhaps call it allowance). Imagine? for 2 hours of your extra work, you’ll get to hire 200 people - Everyone gets to clean the beach faster and possibly wider. Then you arrive there after your work to join the party! Everyone gets happy and you don’t have dirt on your hands, only beer and much appreciation for funding the project. Everyone wins specially mother nature. Imagine those 200 people not wasting electricity wasting time on facebook!

I guess same applies for programmers. You don’t give lame jobs/tasks to somebody, specially specialized programmers without thinking well about it. Although consultancies will go way and beyond to do it because of the “customers are always right BS”. Or I like to call it, “kissing the client’s ass”. But still it’s important to be careful because the underlying effect to that kind of actions goes back to you, the client. Because it affects the cost.

The first thing is, it’s going to cost you a lot of money. If you’re doing agile, one of the best thing about doing agile is it’s flexibility and no argue about that, but the most common mistake is prioritizing. Clients are most of the time clueless in prioritizing! Tip: Consultancies usually knows it better because they’ve been that a lot of times already or perhaps give them the opportunity to do it for you. Also, your idea of execution isn’t exactly the same always as the developers. So work with your team and get to know each other then be happy for the rest of the project lifecycle.

The second thing? What you probably don’t know is, it’s offensive and boring. A developer knows if it’s a an easy job or a hard one. An easy job, it’s ok fine, there’s no problem about it. But if there are more pressing issues, you don’t burden somebody about it and don’t expect them to do that easy and instantly for you, because it will just disappoint you - it’s a distraction to scheduled tasks. Again, it’s called prioritizing but can be worked around by allocation. So here’s how to do it: Give the pressing issues to a senior developer who knows and build things good and have the fixes/bugs/lousy tasks done by a junior developer. Or have a senior guy does the major features and keep him always moving on, then have junior developers to clean it up. Tip to consultancies: Hire a project manager to manage those. Pair programming is a different case apparently. On our case, the pair breaks off to handle acceptance criterias or bugs while one guy still continue with the current stories with only one doing it, that sucks, but that happens.

Third. Please make up for your F*****g mind on your specification. A stereotypical programmer isn’t stupid they smell BS. He knows if you’re wasting his time and they slowly hate you if keep sending lazy/lousy/instant tasks to them. Please don’t piss your programmers, they have feelings too.

Again, All of the above are tolerable, but it really depends on how consultancies kiss their client’s asses. But for some high end ones. well, good luck to you (the client) on your next billing.

Now for consultancies:

1) Lousy tasks are what project managers are for. It’s important that somebody else interfaces with the clients to screen tasks, connect to them, clear them out and understand well the scope and everyone agrees before 

2) It’s important that junior developers exists always on a team. It fills the void that senior developers can’t handle anymore.

3) Another important thing is the availability of someone who can do a good User Interface design. They make everything beautiful specially on chaotic times.

3) This is the main reason where fixed bid projects really suck. Clients tend to change their ideas or realizes things late when they start seeing and experience things visually. Like “change this button from here to there”. Or like this “Oh wait, change the entire way how the user signs up. We don’t want 3 step wizard signups, we only want to make it 1 page” (after killing yourself for working on that for 3 days).

4) As much as possible, don’t start without a designed user interface or wireframe. It’s a very important factor on how system designers frames your stories/projects. Besides the other documents, developers visually seeing what they’ll do will make their job easy.

I’ll end the post now, There’s more to talk about the topic and will find out more soon.

Also: To junior developers, not to hurt your feelings on this post though. Don’t worry about those small lousy tasks that I’m talking about. Your seniors and bosses are very grateful for it. No hard feelings and everyone passes through that, even me years ago.

JT

(note, this post has alot of “I”s. but who cares, it’s my tumblr :p)

Yesterday, I was in a meeting with a client. While in the middle of the meeting, I’ve found myself disagreeing on some of the stuff we’re talking about. Features, business stuff, vision, etc… - it happened a lot on our conversations.

Yesterday, I finally said “NO” to one of my clients. Saying “NO” to him and can’t continue and maintain his projects anymore. Why? that’s for another story. The reason I got in trouble anyway is because I didn’t said “NO” earlier. 

Days, Weeks, Months before that I’ve been doing the same. Unconsciously, I managed to learn it without even thinking about it anymore excluding the one above.

Given those scenarios, I guess saying “NO” comes with experience, when I was young and just a lowly programmer, all I did was follow whatever shit that management or some client is giving. Today, it’s a different situation. Maybe I have the face to actually say it now or I have learned enough on the domain and valid reasons why I’m saying it.

Now my load is lighter and I’m more sane than before. Happy face. So I’ll break it now and will just leave some more thoughts.  

The most important thing I’ve learned by saying “NO” is… It’s not harmful but actually helpful.

I already learned how to say “NO” to a project unless the project has a good business model, marketing plan and passion (by its founders).

I already learned how to say “NO” to side offers because there is much more in life than  earning tons of money. Although I want them lol, but there’s no point of having money when you can’t even go out to enjoy them. Working long hours everyday including weekends, sleepless nights and all the annoyances - they all don’t help if your goal is good life. I remember one time I was in Bali, Indonesia and I can’t even head out because I have to work 8 hours a day. So work anywhere isn’t as appealing and charming as advertised.

I also realized “NO” sometimes mean “NOT THIS TIME”, “NOT NOW” or just literally “NO”.

Most cases I say “NO” because I think.

Some cases I say “NO” because I think it’s not that important.

Some cases I say “NO” because I’m lazy to do it or I have more important things to do than that.

Saying “NO” basically shows and aligns with your organizational skills.

Saying “NO” means you’re concerned with the project and you have a deeper understanding why. Again, experience.

Saying “NO” means you’re conscious about your sanity.

Saying “NO” closes the LOOP.

Here’s some shortcuts on how to use your arrow keys to select blocks of text.

Add this on your ~/.gvimrc file (or similar)

if has(“gui_macvim”)

  map <D-S-Right> <Esc>v$

  map <D-S-Left> <Esc>v0

  map <D-S-Down> <Esc>vj

  map <D-S-Up> <Esc>vk

  vmap <D-S-Right> $

  vmap <D-S-Left> 0

  vmap <D-S-Down> j

  vmap <D-S-Up> k

endif

Then you can now use apple+shift+arrow keys to select blocks of text in MacVim. Lovely :)