81–90 of 90 posts
Prototype a cog in an afternoon; you'll have a much deeper understanding of how that cog should work, and you'll be a better judge of the available cogs.
FrankenCode is a perfectly viable strategy, but it's gross and boring.
Earlier quoted context omitted.
Not being able to write your own code to deploy into a production environment won't get you very far as a software developer. Merely my $0.02.
But unless you're a web host or something, you are not being paid to write web servers. In the limited amount of time you have to solve your business's actual problem, do you want to learn the ins and outs of HTTP, or do you want to learn the ins and outs of the actual problem you are trying to solve?
#1 Rule or programming is: programmers start counting from 0, not from 1.
As an odd corollary, in matters of system administration, the exact opposite is usually apposite: AUTOMATE EVERYTHING.
Earlier quoted context omitted.
But unless you're a web host or something, you are not being paid to write web servers. In the limited amount of time you have to solve your business's actual problem, do you want to learn the ins and outs of HTTP, or do you want to learn the ins and outs of the actual problem you are trying to solve?
deploying is one of those cornerstones that you need to get right once, right at the beginning. #twitter
Earlier quoted context omitted.
Not being able to write your own code to deploy into a production environment won't get you very far as a software developer. Merely my $0.02.
But unless you're a web host or something, you are not being paid to write web servers. In the limited amount of time you have to solve your business's actual problem, do you want to learn the ins and outs of HTTP, or do you want to learn the ins and outs of the actual problem you are trying to solve?
I don't think anyone would write a web server unless they were in that business. But if they were, they wouldn't simply pick up Apache just because they can.
There are always at least two correct sides to every argument.
I'd say it can be simplified even further: THINK before you SOLVE. A natural tendency for programmers/developers is to move towards a knee-jerk reaction of "I'll just start coding this". It's not that good solutions don't come up from that line of thinking; it's more that - as cyman states - there are faster ways to accomplish results if you simply think about how you're going to solve the real problem(s). Once a pro…
I believe this is actually a much better rule. There is the other knee jerk (and a dangerous one) to do the reverse and just use off the shelf kit for large swathes of functionality. We have one contractor who did just this and it currently the project is 3 months overdue as he is reworking large portions and sections so that it can do the things we originally asked of the program ;) Formulate your approach then deci…
I would never buy a library, but I've never had that option either. Every tool I use is open source, and I build small proprietary applications around the open source stuff. (Making web pages and parsing CSV files is not my business domain, so I let the community handle those.) I will say this -- the first step to not writing too much code is to reuse your own "internal" code. It's simple; instead of cut-n-paste-n-mo…
Earlier quoted context omitted.
"Talk is cheap. Show me the code." - Linus Torvalds
The second line is a great counter-argument. In reality, this clever quip is just Linus' way of telling people to go away. He certainly talks a lot about code he has no intention of writing. (He does write a lot of code, too.)
It's easy for me to outline how a great piece of software X is supposed to function, but I'm still surprised every time how much more work ends up going into the actual implementation compared to the conceptual simplicity of the design. So, similar to "writing is thinking" I believe that "coding is thinking" as well.
The first rule of programming is indeed "don't program". But that's not because buying off-the-shelf code makes you more productive than writing code yourself. It's because software solutions are usually worse than manual solutions. Here's a typical example, one I just ran into today. For a course, I need to enter some data into some system that stores grades. It doesn't just store grades, though, it tries to calcula…
tl;dr version: Write code to solve the core problem. Don't write code for the rest unless it's really needed .