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?"

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.

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:Not Ruby

[inKubus]

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. In my opinion the content management side of the business is going to be where we all end up long term, with most "programming" being telling the CMS what to do and what modules to route documents to. So learning some standards like CMIS, OData, GData, and some big document management systems like Alfresco will get you much further than "building web applications". As much as the designers would like to brainwash you that it's all about the UI (and designers are very good communicators so they can), the reality is that UI is a solved problem. At Fortune 1000 companies, you're not going to see much "programming" in the end user stuff. In general, it's middleware. Your career will be much longer if you learn about the data side, and not at a programmer's level but at an analyst level. The number of analysts will be 100 times the number of programmers in 10 years.

Re:Backwards?

[Anonymous Coward]

Clearly someone who has never been a coder.

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:Not Ruby

[Tacvek]

I'd dispute that ruby is dying. Ruby is a well designed language, and works just fine. It will remain around, although when it reaches steady-state it will probably not be a particularly popular language anymore.

What is dying is Rails. Rails has been one of the largest driving forces for Ruby. And make no mistake, it is an excellent web MVC framework. Consider that most web MVC frameworks that have come since rails have incorporated at least one component of Rails. For example Microsoft's ASP.NET MVC comes with a routes system inspired by Rails, and has a definite convention over configuration design.

Rails is dying in large part because the MVC frameworks of other languages are now comparably easy to use, meaning that the advantages of using Rails frequently do not overcome the disadvantage of learning a new language, namely ruby.

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.

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.