Calling All Coders: What was your roadmap?

[justo_tx]

If the latter, he should get down to fundamentals without the aid of frameworks. He should have the skills to be able to take an idea, open up Notepad, and turn it into a reality. Once he's got that down, he can start worrying about frameworks to make his life easier. If you want to be a developer who builds profitable applications from scratch, you should have the skills to write your own framework, before relying on others.

Or to use your analogy, if you want to manufacture bicycles, you need to know all of the parts inside and out. You can't just take an existing bicycle, make a few tweaks, then sell it as a new product. Well, you can, but...

I think you're losing sight of what the end goal is. You aren't selling your code, you are selling the outputs of your code. If you are building applications your customers cannot even see your code. Your customers don't care if your code is hacked together inefficient crap copy and pasted from google and stack overflow or if it's the most elegantly terse algorithm ever to cross a compiler. They just don't care, they just want their air travel booked, blog posted, image tagged, or whatever; all they care about is that they accomplished what your application promised to do.

Now if your code IS your output, i.e. the linux kermel, the Node.js runtime, the Rails framework, well then you would be right but that's not the discussion we are having.

I'm not trying to split semantic hairs on what a "framework" is, but ultimately a framework is an abstraction. If the Rails framework (or .NET MVC or Django) is an abstraction that must be eschewed when getting your fundamentals down then why stop there? Do you ditch the OR/M and go back to working with array based DB result sets from an ODBC driver, and if you didn't code the ODBC driver yourself then that's another abstraction that must be recreated. This isn't mean to be a "reductio ad absurdum", I think it's they're legitimate questions if you can't make the distinction between your code being a means to an end instead of an end in itself.


EDIT: All that being said, I enjoy the shit out of learning new development methodologies, languages and frameworks and then writing great code, and that becomes it's own risk; rewrites and new frameworks or the getting the perfect DB schema make seemingly legitimate persuasive reasons for putting off accomplishing your goals. It's something I always have to keep in the back of my mind.

 

[justo_tx]

Why hasn't suddenly_ass made an appearance in this thread yet?

 

[emp]

He is busy coding the perfect ass, of course.

::emp::

 

[crackp0t]

I think you're losing sight of what the end goal is. You aren't selling your code, you are selling the outputs of your code. If you are building applications your customers cannot even see your code. Your customers don't care if your code is hacked together inefficient crap copy and pasted from google and stack overflow or if it's the most elegantly terse algorithm ever to cross a compiler. They just don't care, they just want their air travel booked, blog posted, image tagged, or whatever; all they care about is that they accomplished what your application promised to do.

Now if your code IS your output, i.e. the linux kermel, the Node.js runtime, the Rails framework, well then you would be right but that's not the discussion we are having.

Correct, you're selling a finished product that does something the customer wants. However, they do care if it's inefficient crap code. They might not know they care, but they'll be pretty pissed off when the UI becomes unresponsive, when it takes you 6 months to add a basic feature, or when adding a feature breaks a different feature that was previously stable. Which are all bi-products of poor programming practices and poor design choices. There are many more examples of what poor design choices and poor programming practices can lead to.

I'm not trying to split semantic hairs on what a "framework" is, but ultimately a framework is an abstraction. If the Rails framework (or .NET MVC or Django) is an abstraction that must be eschewed when getting your fundamentals down then why stop there? Do you ditch the OR/M and go back to working with array based DB result sets from an ODBC driver, and if you didn't code the ODBC driver yourself then that's another abstraction that must be recreated. This isn't mean to be a "reductio ad absurdum", I think it's they're legitimate questions if you can't make the distinction between your code being a means to an end instead of an end in itself.

If you don't understand the design choices that goes into the ORM library you're using then yes you should ditch it, because if something is wrong with it in an edge case that you happen to hit you have no chance at fixing it properly. That sounds far fetched, but it actually happened to me.

 

[suddenly_tits]

Why hasn't suddenly_ass made an appearance in this thread yet?

I've been eclipsed by suddenly_ass once again! people never demand suddenly_tits anymore

 

[netbert]

The excitement about every detail of new technologies wanes with age, so be prepared for that.

That only happens because they aren't actually new technologies. Most of the time they are old and familiar concepts that have just become a new fad again (but wrapped up in shiny!)

 

[amateursurgeon]

Correct, you're selling a finished product that does something the customer wants. However, they do care if it's inefficient crap code. They might not know they care, but they'll be pretty pissed off when the UI becomes unresponsive, when it takes you 6 months to add a basic feature, or when adding a feature breaks a different feature that was previously stable. Which are all bi-products of poor programming practices and poor design choices. There are many more examples of what poor design choices and poor programming practices can lead to.

I really, really, really wish that was correct... but in my experience it's not.

I used to run an IT support company, and most of the COTS software we had to deal with was appallingly written, often using weird non-languages like Visual Foxpro or dBase. The end users knew it was pretty shitty software, but they still bought it (often for tens of thousands of pounds) and kept paying for it, because it solved their problem better than anything else.

In almost every case I can think of, quality was secondary to domain specificity. End users would just pay someone like me to paper over the horrendous problems, and keep paying large maintenance fees.

Changing a vital software system is so painful for a business (because of training, data migration and adaptation costs), that they'll put up with almost any amount of crap to avoid having to do it. The only time they can really refuse a system on the basis of shitty quality is BEFORE they buy + implement it, and it's very unusual that (small businesses at least) have the technical chops to make a good judgement about that. Seriously, buying big software is so incredibly hard for a non-technical person. They'll be lucky to get something that works at all, never mind works well.

 

[crackp0t]

I really, really, really wish that was correct... but in my experience it's not.

I used to run an IT support company, and most of the COTS software we had to deal with was appallingly written, often using weird non-languages like Visual Foxpro or dBase. The end users knew it was pretty shitty software, but they still bought it (often for tens of thousands of pounds) and kept paying for it, because it solved their problem better than anything else.

In almost every case I can think of, quality was secondary to domain specificity. End users would just pay someone like me to paper over the horrendous problems, and keep paying large maintenance fees.

Changing a vital software system is so painful for a business (because of training, data migration and adaptation costs), that they'll put up with almost any amount of crap to avoid having to do it. The only time they can really refuse a system on the basis of shitty quality is BEFORE they buy + implement it, and it's very unusual that (small businesses at least) have the technical chops to make a good judgement about that. Seriously, buying big software is so incredibly hard for a non-technical person. They'll be lucky to get something that works at all, never mind works well.

Okay, point taken . I'll say that is true as well. I have had those kinds of gigs and they're horrible. I purposely refuse them, because I don't actually have to take them to put food on the table (probably why they slipped my mind).

You're also correct about small businesses. I have a friend that funds small start ups and I occasionally help him. The last thing he had me review I wanted to punch the developer and / or have him arrested for professional negligence (I know that's not possible, but it should be). Storing CCs in plain text, sql injections all over the place, and the list goes on. I'm still a little pissed about it. This was POS (Point of Sale) software as well that was IN USE! Since my friend came in and had me review the code it's not use anymore (thank god they were able to revert it back) and it's being completely rewrote by someone who isn't a moron. I forgot to mention the software was in use in the EU where they don't fuck around with user privacy and data leaks. A child with an sql chart could have stolen every CC.

 

[Wicked Ice]

Effective Programming: More Than Writing Code

=> [ame="http://www.amazon.com/Effective-Programming-More-Writing-ebook/dp/B008HUMTO0"]Effective Programming: More Than Writing Code [/ame]

 

[Suddenly_Ass]

Why hasn't suddenly_ass made an appearance in this thread yet?

Believe it or not, I try not to post in threads where there are serious and helpful conversations going on - just doesn't seem appropriate.

But since you asked.

suddenly_tits, you are still da man.

 

[flx89]

I really like the tutorials from Lynda.com... It's a good point to start

 

[boatBurner]

I really like the tutorials from Lynda.com... It's a good point to start

I am actually subscribed to Lynda already, currently studying the basics of Ruby.

That paired with Michael Hartl's Ruby on Rails Tutorial shared by dchuk has me with plenty to learn at the moment. I'm more interested in concepts and structure than I am in syntax (which seems to be more about "muscle" memory than comprehension).

And I'm incredibly excited and impatient. I want to start developing and fucking projects up already. And more importantly, I want to sharpen this skillset faster and more proficiently than my peer group.

Specifically, I would like to be an intermediate rails developer with a basic understanding of Ruby by January. I don't think this is impossible. But what would you say, as an employer, if I told you I started learning Rails in October and was applying for an entry level developer position in January?

 

[emp]

Read this:

[ame="http://www.amazon.com/gp/product/020161622X/ref=as_li_ss_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=020161622X&linkCode=as2&tag=blindapeseo-20"]The pragmatic programmer[/ame]

::emp::

 

[dchuk]

But what would you say, as an employer, if I told you I started learning Rails in October and was applying for an entry level developer position in January?

A good employer won't care about timelines and will be more interested in your abilities. That being said, keep me updated in your progress.

 

[flx89]

yeah, most of the tutorials are really good to understand the basis.
I learned a few about javascript from there

I am actually subscribed to Lynda already, currently studying the basics of Ruby.

That paired with Michael Hartl's Ruby on Rails Tutorial shared by dchuk has me with plenty to learn at the moment. I'm more interested in concepts and structure than I am in syntax (which seems to be more about "muscle" memory than comprehension).

And I'm incredibly excited and impatient. I want to start developing and fucking projects up already. And more importantly, I want to sharpen this skillset faster and more proficiently than my peer group.

Specifically, I would like to be an intermediate rails developer with a basic understanding of Ruby by January. I don't think this is impossible. But what would you say, as an employer, if I told you I started learning Rails in October and was applying for an entry level developer position in January?

 

[amateursurgeon]

Something to add here - employers are often very interested in "commercial experience", rather than just what you've built for yourself. So it might be worth taking on a project or two at a low price (or free), just to build your portfolio.

...or you could just build one of those SaaS ideas. Who knows you might shortcut the whole process and find you don't need an eimployer after all?

 

[absolute]

...or you could just build one of those SaaS ideas. Who knows you might shortcut the whole process and find you don't need an eimployer after all?

This. And if it turns out that you still need a job, get at least a few people to sign up and use/test your SaaS. Then you can talk about that shit in job interviews.

 

[Bofu2U]

To add to the learning materials/places for Rails:

+1 Railscasts
+1 CodeSchool (especially for if you want to learn something that your "team" will start using instead of just you, like RSpec, etc.)

But that's just more my learning style. Narration & functional vids going through a process and me doing it along side is the best way that I learn most of the time. Cause & effect.

 

[Mahzkrieg]

Some hilariously awful advice in this thread. Honestly.

And I'm incredibly excited and impatient. I want to start developing and fucking projects up already. And more importantly, I want to sharpen this skillset faster and more proficiently than my peer group.

Yeah. That's precisely why you jump into Rails first. You can build as you go and figure it out because you're not a retard.

That will compel you far more than whatever the fuck the counter-advice in this thread is. What:

Week 1: If-statements.
Week 2: If/else-statements.
Week 3: Addition
Week 4: How to write a loop
Week 5: How to write a loop, continued.

And you can rule out microframeworks like Sinatra, which I don't understand why people recommend to newbies at all. Maybe it seems like a good intermediate step on paper, but writing glue code between contribs with zero post-README documentation is not newbie friendly. Railscasts are, though. Hartl's Rails Tutorial is. I don't see any Sinatracasts. Frankly, hooking up Active Record to Sinatra is a pain in the ass, and the Active Record API is extracted from Rails, anyways. It's maintained in the Rails github root by Rails contributors. So you end up trudging through one of the largest facets of the Rails learning curve and reading Rails AR docs... but outside of the Rails ecosystem. Why?

Also, the notion that programming isn't a "viable longterm career solution" because, what, you'll be behind if you go into a coma for a decade? Or get stranded on an island away from a computer for too long? What the fuck. :1orglaugh: Just sounds to me like someone that hates programming and isn't compelled by the power to build and create great things using nothing but a terminal and a throne of empty mountain dew bottles.

$30k for junior devs? That's half of the lowest wage I've ever heard someone start out with as a Rails developer. If you're in an industry that pays American programmers $30k, maybe you aren't the Who's Who of people that can give sagacious career advice to a fledgling developer.

 

[kumansk]

Say you just want to learn either PHP or Ruby on rails to start up a site similar to tumblr with fancy web2.0 graphics and a complex user interface. But you also need stability in the long term in case it grows exponentially as well as the ability to make small/large changes. Which one is better?