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.

Re:Try Not To Code

[TheRaven64]

I wouldn't trust most backend developers with good, usable design because they assume that the users should be "smart enough" and do not realize that most websites aren't usable enough.

The simple solution here is to put your most talented developers to work rewriting your customers.

Re:Try Not To Code

[syousef]

Most importantly the project manager got your respect, and I dare say the respect of others on the team. Tech staff hate it when they have a manager that understands nothing and couldn't code their way out of a paper bag. Proving that he wasn't one of those would have been very good for his reputation and team morale. Pity he seems to have made the cardinal mistake of annoying those above him. Did he end up being fired or put aside? Then the team would have said "You know old so and so, he wasn't so bad. Not a great coder but at least he proved he could do it".

Personally I think managers should pair program with an experienced team member for at least half a day about once a month. I'm in the minority.

Re:Try Not To Code

[swalve]

This is one of the big mistakes in the IT field, I think. Coders *should* know the big picture stuff, so they don't start going down unsustainable paths. My boss is one of those "insulator" bosses, and while he does it out of the belief that it is the right way to do things, it leads to problems. Grown ups *want* to know where they fit into the bog picture.

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

[dkf]

Ruby is dying fast.

That's some of the most robust "dying fast" I've seen in a while. How many decades do you think we'll need to wait before ordering the hearse?

Re:Not Ruby

[telekon]

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

advice

[eexaa]

The advice I give to everyone having trouble to get a 'whole project' running is to write a simple game. Like, say, something from Spectrum, or arkanoid, or a zombie pwning game. Nearly everyone started on it, it covers a pretty large amount of problems to solve, and it's fun to do.

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!

Programming Fundamentals

[Anonymous Coward]

I highly recommend this course. It's from stanford and has all the lectures online. It teaches you how to think about programming.
http://see.stanford.edu/see/courseinfo.aspx?coll=824a47e1-135f-4508-a5aa-866adcae1111

Becoming a programmer

[Aladrin]

At my previous job, we had a CSR that we found had an aptitude for testing. So we made him a tester. He soon started to feel like you do: that he wanted to be coding.

He started learning to code on his own time, in the language we were using at work. He found someone in an IRC chatroom that needed some coding done in that language, and he helped them. A couple times. And a few other people.

And most importantly, he told the other programmers he was doing this. We cheered him on, and we told the bosses. He was eventually tried in-house as a programmer, and turned out to have a good aptitude for it.

In just a few years, he was just one of the team and not 'the guy that came from CS, can you believe it?'.

In short, start learning and using the language on your own time, and tell people at work about it.

Re:Backwards?

[Anonymous Coward]

clearly someone who has never been a manager

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.

If you want to get more into programming...

[DaveHowe]

Why not look into contributing to an Open Source solution in your chosen area? see if you can find (for example) some PM tools that almost are good enough, and make them better?

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.

CS != Software engineering

[rocket rancher]

Going to a CS department with the expectation of learning how to be a commercial code jockey is not an optimal strategy. Perhaps this is off-topic, but I'll try to keep it brief and focussed. One recent poster wanted to take a CS degree to become a better coder, but wanted to skip the gen ed requirements that four year degrees have, and this poster also suggests that taking CS courses will help him be a better coder. The thing is, CS is not about coding. It's about investigating the nature of computability and developing models and the mathematical tools capable of describing the models in rigorous ways so that they can be analyzed. You already have to be a good coder if you want to do CS, and if you aren't, you need to take programming courses which are usually found in engineering or MIS departments, not in CS departments.

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.

Enjoy a nice drink...

[Panaflex]

Sure, go home, crack open a book on programming and sip a cold one. Do some chapter projects, get to know a bit everyday and you'll learn a lot. Start with other peoples samples and learn how to improve or change parts to do what you want.

But unless your truly devoted you won't be part of the code staff anytime before your project is done. At the very least you'll gain an understanding of how it works and what causes delays.

Some people are pretty amazing... there was a kid who learned C coding and submitted his first Linux patch within 6 months of touching a computer for the first time. But chances are that you don't have 8,000 hours time and a rabid passion to devote to get to that level of understanding.

Try MIT Open Courseware

[LibRT]

MIT Open Courseware offers (for free) CS, including video lectures, assignments, exams etc. http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-00-introduction-to-computer-science-and-programming-fall-2008/video-lectures/

Pick one

[AtlantaSteve]

Ultimately, you can either be a PM or a developer. I agree with other comments, that trying to be both simultaneously invites failure. That said, it seems like most careers in I.T. involve "stepping sideways" into something along the way.

I'm more accustomed to seeing this flow in the opposite direction... people who start off as developers, yet later in their careers step into management, hands-off architecture, pre-sales support, etc. However, there's no reason why you can't flow the other way. You would have a hard time being taken seriously at something truly hardcore, like development of compilers, kernels, or large enterprise back-end systems. However, who are we kidding... **most** of the JavaScript coders I've ever met were HTML designers who gradually stepped into development, and a ton of PHP or Ruby guys just kinda stumbled into it with no Computer Science background at all.

However, if you want that career path... you ARE going to have to "shit or get off the pot", and say farewell to being a PM (at least in the sense that most people use that job title). A true PM stays the hell out of the codebase, although you can pitch yourself as having "team lead" experience if you want to leverage that background. As far as making the transition, do the same thing any other entry-level programmer would do. Pick up a degree in the evenings, or maybe some certifications (they can matter a little bit at the entry-level). Dive into an open source project, so you have some resume code floating out there. Make your company aware that you want this transition, and be prepared for the fact that you likely will need to change companies for it to really stick.

Also be aware that you may be talking about a pay cut at first, because you're going from being an experienced PM to an entry-level coder. However, senior coders make more money than PM's... so you can be better off in the long run as far as that goes.

Good luck.

Re:"Designers" are taking over. That's a problem.

[ranton]

When I read your post, it sounded like you were describing some of the best trends in software development (not problems). Having designers take control of the user experience away from the developers is a good thing in my opinion. Unless they suck at their job, of course, but the same can be said of developers.

These days, however, we're seeing the "designers" deciding how UIs, and even the software as a whole, are to behave, from beginning to end. The software developer is there to merely implement whatever the "designer" wants, without any ability or power to make decisions themselves.

Hallelujah. Thank god designers and business analysts are keeping developers from creating horrible interfaces and forcing unusable workflows on end users. I don't think you see too many developers complaining that they aren't allowed to fumble around with user interface design anymore.

This is exactly what we've seen from each organization and group that you mentioned. Apple, for example ...

Are you honestly using the best example of designers having a bigger impact on a successful company than developers to illustrate designers run amok? Does anyone dispute that it's the aesthetic excellence of Apple products that has made it into a successful company, as opposed to technical excellence?

It's time for software developers to make the decisions, rather than "designers". The priorities and concerns of the software developers are much better aligned with those of the actual users. The applications may not look as pretty, but that's easily ignored if they work well.

I could not disagree more. As the software development field continues to mature, the last thing we should do is go back to the dark ages when software developers were primarily responsible with the user experience. Keep us doing what we are good at: implementing the great ideas of great designers and UX experts.

Programming, paths, and book recommendations.

[Koda]

There's are plenty of things that are great about Ruby on Rails, but I don't recommend *Rails* as a starting point. Without any background in programming, SQL, HTML, or JavaScript, there's a good chance you'll overwhelmed, or at least confused. RoR covers a LOT of ground. I think Ruby, Python, and Groovy would all be good languages to start with, but don't worry about picking "THE" technology yet or a full framework. Even if you do pick the "right" technology that you make into a career, there will be plenty else to learn, now and in the future.

Here's are some specific recommendations:
A) First, there is no need to quit your job yet. Consistently use some of your evenings and weekends to explore and learn. If you find out you don't like one of the technologies I've recommended, don't sweat it. It may not be for you, or it just might be the wrong time.

B) Try some programming, and see how you like the logic and puzzle-solving part of it. Here are two books I'd recommend to get started, in no particular order:
1) "Python Programming: An Introduction to Computer Science" (Second Edition) by John Zelle
2) "Why's (Poignant) Guide to Ruby" by _Why the Lucky Stiff - http://mislav.uniqpath.com/poignant-guide/

C) Try some web development and see how you like the design, layout, and organization of it. Start with the book "Head First HTML with CSS & XHTML" by Elisabeth Freeman & Eric Freeman. You'll learn HTML the new school way, where presentation and structure are separated (and the web is better off for it).

D) Try visiting some user groups for different technologies, like Ruby on Rails, Groovy on Grails, Java, Python, .NET, MySQL Adobe Flex, whatever. You'll get a feel for the culture while learning new things.

E) Once you finish the above, there are several directions you can take:
1) Want to program more? Sign up for a college class on programming. It doesn't matter whether it's C, Java, shell scripting, or whatever. Just take a class to continue developing your programming skills and develop an appreciation for the different aspects of the world of programming. And a class at a community or technical college can be perfect for this.
2) If you're continuing down the programming path, buy another book on Ruby, Python, or try something new like Java, JavaScript or PHP. If you want something more hardcore, check out "The Joy of C" by Lawrence Miller and Alexander Quilici.
3) If you continue progressing in programming, and/or if you really want to get into Ruby on Rails, Groovy on Grails, Spring, or any framework, you'll probably want to take a class on Intro to Databases or just pickup a book on SQL. If you liked Head First HTML book, then check out Head First SQL, and/or get the very concise "My SQL Crash Course" by Ben Forta. Knowing basic SQL and database essentials will make you better with Rails, Grails, Spring, or any framework. Or if you really like SQL and organizing things, database development and/or administration can become an entire career. And you may get into data mining or data ETL (over the years I've been exposed to Microsoft SQL Server, Sybase, MySQL, Oracle, Informatica, and lately to Microsoft SSIS).

F) If you've made it this far, you've probably picked your path, and possibly found a programming language you love. Your next steps may be one of the following:
1) Dive fully into Rails, Grails, Django, Spring, JSF, force.com, or another framework.
2) OR Learn more HTML, CSS, and JavaScript. Play with JQuery, Dojo, or another JavaScript library.
3) OR keep taking college courses, perhaps hardcore CS with Calculus, Physics. That's not the only route, but this will take you from good to great in programming. Don't overlook other options, including a BA in Computer Technology.
4) OR if you're not not digging hardcore programming, school, and/or you cr

Re:"Designers" are taking over. That's a problem.

[Jane Q. Public]

No, I didn't miss the point. I'm pointing out that he did.

"I very much doubt it was an engineer who came up with the scroll wheel idea for iPod."

Perhaps not... but you had better believe that an engineer was the first person they consulted before moving ahead with the idea... which is the big problem I see, which has not been acknowledged by the other posters here: in far too many situations, designers know about design and little else, and make their designs without confirming or consulting about the design's actual feasibility. Which makes the lives of everybody else in the company miserable.

Design is great... but engineering should be in on the design process. When designs are approved on their own, before any input from engineering (which happens quite a bit in my experience), the results are often a disaster.

The case thing was not intended to be an example of software engineering, and I never implied that it did. But software software UI/UX design has a lot more parallels with physical design than many people acknowledge. There is an awful lot of overlap: Where do we put the buttons? How large do we make them? How do we label them? What is the sequence of operations that will make work flow go most smoothly? Etc. At some point it all comes down to Human Engineering (or Industrial Psychology, depending on your POV).