Ask Slashdot: Stepping Sideways Into Programming?

thundertron writes "I'm a 28-year-old, non-technical, UX-focused Product Manager at a startup. Overall I'm very happy with my work, but I'm endlessly frustrated that I'm not committing code. I love the few occasions where I commit some front-end code or put together a fairly sophisticated query, but if the onus were on me to put together an entire site my hands would be tied. I've thought about going back to school (or even taking time off from my career to take courses) in CS to immerse myself in programming. The flip side is that I know I won't want to do that forever — I won't want to be employed primarily as an engineer because I like too many other aspects of the business. My best option seems to be to dive into Ruby on Rails and just pick up what I can in my spare time. Perhaps others in the Slashdot community have some suggestions/recommendations?"

Comments

Try Not To Code

[WrongSizeGlass]

One of the most important aspects of a PM's job is objectivity. Once you're part of the team contributing code you'll face the difficulties of having to kill some of your own ideas or contributions. It's never easy to be on both sides of the line when your dealing with more than a few people on a project.

Re:Try Not To Code

[nine-times]

I agree with this-- you need enough knowledge to judge the work of the people you're managing, but often enough, it's detrimental for managers to "pitch in".

I'm sure there are people here who would disagree. If you're the person being managed, sometimes it's nice to see your manager pitch in and help. They're suddenly doing "real work". And as a manager, sometimes it's helpful to experience first-hand the difficulties that your subordinates are facing. It gives you perspective, and it gives you a better grasp on how to help your subordinates.

On the other hand, one of the primary jobs of a manager is to be detached from some of the nitty-gritty details and to be keeping an eye on the big picture. It might be that while everyone else is obsessed with making their code perfect and efficient, your time is better spent looking at the product as a cohesive whole and figuring out whether you're actually achieving your goals. It's a challenging job in its own right, and it's a job too often neglected.

Re:Try Not To Code

[donscarletti]

Coding is sometimes the only way for the manager to understand the problem being faced. Also it is sometimes a good way for the manager to communicate with the team. We had a project manager who decided to implement a small feature that everyone else said couldn't be done in a short timeframe. Firstly, he proved it could be done, secondly through this experience, he then understood enough of the system to not keep asking stupid questions and continue sounding like a retard in meetings. Turned out he was a shit coder, but who cares, we just got someone to re-do it who knew what he was doing once the basic solution had been prototyped. The only person annoyed at him was the CTO, but he was just a relic of the era that systems were so simple, you could write them correctly the first time.

I would say that a project manager should not be making personal contributions. If he is a craftsman who loves his code, then that counts. But mostly the worst thing for objectivity is not code but contributing concepts, designs, theories and of course personal preferences and experiences.

Not Ruby

[Anonymous Coward]

Go Python.
http://diveintopython.org/
Then if you feel you need more jump into Perl. With an understanding of those two languages you should be set to pick up (just about) any other languages easier.

Just my opinion.

Re:Not Ruby

[telekon]

Yeah, Ruby is not what I would do either. Ruby is dying fast. While I'm not a huge Python fan, it's not a bad language. If you're on the UX side you should look at learning HTML5 and javascript libraries like jQuery and javascriptMVC.

Funny, after attending RailsConf last month, I'd say that reports of Ruby's demise are greatly exaggerated. In fact, if your perspective comes from a UX-oriented side of things, I couldn't imagine a better language/framework for you to get started with than Ruby/Rails.

It's only moving more in that direction. Rails 3.1 will include jQuery as the default JS library, supports CoffeeScript and Sass by default, and the new asset pipeline makes it easier than ever to build out your app with a backend REST API and do the heavy lifting on the client with MVC frameworks like Backbone.js

What you should learn first depends on your goals. Are you just curious about programming? Or do you really want to make a shift in your career path? If you work in a Ruby/Rails environment, and really want to get into the coding where you work, then that's the obvious choice. If you're completely new to coding, Ruby is also a marvelous first language to learn. I started with C and Perl, and I WISH Ruby had existed then.

If you just want to understand the dev side of things better, you could start by learning the basics of web development from something like Code School. Their Rails for Zombies course is a great place to start, and better yet, it's free. If you want to get your Ruby up to snuff, try Edge Case's Ruby Koans.

IMHO, much of the Ruby-hating is jealousy. If you're new to programming, you might be unfamiliar with holy wars. Coders develop religious issues over everything from languages, to tooling, to operating systems. You'll have to decide for yourself where you want to start. But Slashdot opinions are probably not the way to make that decision. My advice: Pragmatic Programmers has a very basic intro-to-Ruby book called Learn to Program. It might be too basic, it might not. But then you can check out Seven Languages in Seven Weeks and decide whether you prefer Ruby, Scala, Erlang, Clojure, etc.

I heartily encourage you to learn to code, whether you find it professionally or personally rewarding. Maybe you can contribute to some open source projects, even if you decide it's not right for your career. Either way, have fun with it.

In interest of full disclosure, I'm a committed Rubyist. We tend to be opinionated loudmouths. But also beware the Pythonistas. They tend to be disgruntled contrarian CS students.

Re:Not Ruby

[telekon]

Dude, yeah! Were you the guy with the faux-hawk and glasses?

CS != programming

[cheeks5965]

first, I think it's awesome that you want to get more education. But you need to keep in mind that there's an enormous difference between computer science and programming (CS!=programming). If you want programming experience or new languages then there are many avenues (self taught and other).

CS is mostly abstract - algorithms, math, etc. you could get a good CS education without needing a computer. It's like the difference between medical school and being a doctor. If you want to be a better doctor then going back to med school wont' make any difference.

Hope this helps. Good luck!

Re:Backwards?

[Anonymous Coward]

Clearly someone who has never been a coder.

Re:Backwards?

[yarnosh]

Only if they're seeking money. A programmer who actually cares about programming doesn't want to give it up. Personally, I think technical lead, project manager, or architecture is about as far "up" as I care to go in this business. Beyond that, you're divorced form the code and that's just no fun.

Code reviews

[roman_mir]

Maybe you want to schedule 1-2 code reviews per week and participate in them first, just observing how the developers do it?

Start from there, then you'll be in better position to judge whether this is something you are really interested in.

Keep it as a hobby/part-time endeavor

[Dr. Winston O'Boogie]

I would not suggest sacrificing salary earning years for a temporary career change, which is what I see as the summary of the situation. To do anything for an entire career and be happy requires that your are extremely passionate and interested in the field. I am not sensing that sort of level of interest, and that the priorities here are to be winding up doing something other than engineering in the long term.

I can understand feeling bad about not being able to contribute a certain way in your current environment, but everyone is limited in the things they can contribute in some way. It is a bit of the maturing process to be able to settle for not being able to do everything (as much as many of us would like to).

If the desire to program is deeper than I am giving credit for here and you are willing to sink significant time into, I suggest viewing the language/programming environment as the tool, and the problem as the focus. If your goal is to set out to "learn ruby-on-rails", you'll not get much out of it. If you goal is to solve a particular problem, and you happen to choose ruby-on-rails as the way to realize the solution, that is the way to learn something the most important skills you need as a programmer (and what will be relevant when the technology trend-du-jour changes).

There's all the resources you need on-line at your fingertips to learn as much about programming as you want, so it is all a matter of how much you are willing to sacrifice your free time and energy to dive into it.

One last tip: If you focus on real problems that interest you and not academic exercises, you will learn the important skills faster.

Programming is a CS tease, self-teach instead

[vlueboy]

It's just that having the degree doesn't set you too far ahead of the pack in this economy. While you're studying others are sharpening their resume in small jobs till their skills harden to the point that nobody even asks for proof of a degree when they see a years worth of related bullet points.

I'm in a similar situation to yours career-wise. Started working tech support around age 17 and since then only desktop support gigs have been offered. This summer, I finally stopped getting typecasted, thanks in part to a remote Unix server operations support gig that somehow left some programming-relevant buzzwords in my resume that I could actually prove semi-daily use of. Without the shell experience gained there, I wouldn't be working with front-end code. I'm at a small company and still transitioning, since the assignment is a short paid internship. My resume will finally say that I've done development full-time, rather than call-center or user-facing jobs.

My first suggestion to you is to re-check yesterday's discussion , which was a refreshingly civil rehash of "CS degree isn't programming, yada, yada." Make sure you scale it to >120 comments to get the most detail out of it; just take a break every half an hour to think how the comments apply to you and give it a couple days to review the whole thing seriously. Even to IT insiders, it seems that a CS degree isn't understood --I reluctanctly got one, and somewhat wish I had taken a 2 year degree at a tradeschool approach instead of being forced to plough all the way thru advanced Calculus, Math theory and a bunch of "core" humanities classes. At our age you are well rounded as you'll get and your skills will not really benefit from the degree's forced requirements... unless you quit your job to go fulltime into the 4 CS year degree. Only around half of CS classes are coding, so your job might actually be providing you with more hands-on experience with a single project than you get out of public colleges' degree programs for a whole semester.

Anyways, since you are already writing SOME code and queries towards your company's codebase and bottomline, then you don't need a full 4-year CS degree if you're looking for future jobs at mid-size and small places --the resume's degree blurb is to secure your FIRST programming job, which you indirectly are already in.

So, try to learn the languages and environments on your own (time is hard to find, but force yourself to do little things like regularly trying out examples at code-snippet blogs.) It's very important that you regularly use one or two big IDE's (Eclipse, Visual whatever) and vi / emacs for shells scripts, php and xml. Get familiar with CVS and Maven for code repositories; try out tutorials on youtube to see how they work, and force yourself to default to an Ubuntu 10.04 boot so that you have a shell handy, a compiler and are only apt-get away from Eclipse and other things. If you can live daily with tools that the other devs have, then you're a step closer to slowly push your way... oh, and since you're not a coder at the current company, you'll probably not be given a chance there --ever. A jump away might be the only way; chicken and the egg, really. It takes a good bullet point or two in your resume about "experience with X" programming skills that a junior position for a full-time programmer will appreciate. And without temp agencies, it's hard to kinda make the jump, so it can take you years to get a lucky break.