Recently, there's been a distinction between a "developer" and a "programmer". Forgive me, I'm not citing the source as I don't feel digging around in Google for a while would help make this point any better, but I read an article stating that "Developers take pre-fabricated items and glue them together, as fast as they can, doing as little programming as necessary, where programmers convert caffeine into code; they live for the sheer idea of programming".
While this holds a good deal of truth, I have my own take on it....
Given I've been doing a great deal of concentrated programming per day every week for the last few years, I feel that I am justified in presenting my own development process and ideals that I find have proven themselves time and time again.
For starters, I agree wholeheartedly on use/modify what's already out there. It makes no sense to reinvent the wheel and introduce errors/create a triangle out of a circle. From a professional standpoint, using pre-existing software and modifying its concept or actual code is many orders of magnitude faster than creating it from scratch. Even horribly mangled spaghetti code is a better starting point than nothing.
Now, my tried and true methods has consisted of this:
Creating applications as fast as possible from existing components. If it doesn't exist, I write something quickly, piggybacking off of other's prior art. This solves the solution of delivering to your client quickly, and being able to get more work in, faster. It takes care of having to write more tests, and introduces less errors. It also follows my mantra of JFDI to a T.
Once this is done, go back and refactor, and make better. This allows you to document things, improve tests, add additional features, and improve the community as a whole. Distribution is key here, more eyes, more fixes.
Get involved, and stay involved, in your framework community that you use. Whether you're a core developer or not, read the TODO lists, patch, fix, contribute. Lather, rinse, repeat. I say spend most of your time here, as things will trickle downhill and you will find yourself having to write less and less boilerplate code and your applications will get to a deliverable state faster and faster, with more reliability and consistency. How many damn ways are you going to search for items? How many ways can you create a blog? What's the end result look like? They're pretty much all the same. Time well spent is optimizing these features from the inside out.
Long story short: HEAD IT OFF AT THE PASS. Fix it at the ROOT of the problem, so that people in the future don't have to use shitty hacks over and over that are probably going to break anyway.
I hope this provides clarity for some and is useful for something other than my own mental sanity in the form of a brain dump :-)
Nice entry, here's my feedback for those interested.
Indeed 'developer' is the more formal variation of 'programmer' but no one is saying one is better than the other.
Sorry, but I disagree with your view that "even horribly mangled spaghetti code is a better starting point than nothing." I think that in that case it is better to start from scratch, e.g. back to the drawing board, rather than becoming victim to the quicksand.
I believe that getting a working prototype up and running should be the main focus of all development activities. Scrum tells us that each development iteration cycle should result in a potentially deliverable product, be it a cardboard mock-up using scotch tape and rubber bands, to a full-fledged GUI interface connected to a real working database.
I would recommend NOT refactoring too early. Refactoring involves major changes to the software, bringing with it inherent risks of breaking the system, and should only be attempted when absolutely necessary and definitely not before the code is stable.
Indeed there is a fine balance between spending too much time looking around for answers and using your own creativity to produce a solution (which is more often than not right under your nose). How many of us use good old Google too quickly as an easy crutch, rather than keeping our own grey matter oiled through creative thinking. Scanning Google results can be very time-consuming and inefficient.
Finally, here's one you left out that I believe should never be underestimated: identify major risks and tackle them early before they come back to haunt you when least expected (usually right before the important product launch).
Hope this helps.
It have a lot to do with Ranking!
Personally I feel that the term developer implies a higher rank than programmer.
There are many people involved in creating software at any company or enterprise.
You have:
project managers and facilitators
Designers and Architects
Developers, coders and programmer
Testers and QA
Systems Analysts and Business Analysts
Product Managers
Each have a different focus and role, and depending on your organization, some roles will have a higher class compared to others.
In some organizations Business Analysts are at the top of the hierarchy, in others the programmer and Engineers is at the top.
I worked at places where implementation engineers were the best paid and most valued.
And I've heard of places where programmers were kings, and they had more power, career potential and were better paid than anyone else
It really depends on your organizational culture
I do believe that the debate you suggest is just one that is trying to restore respect to the programmer, who is nowadays is really at the bottom of the ladder, its trying to give him a mystic a prestige!
My point is, you should really pick the right organization for the type of work you prefer doing! Don't work too long at place where you are perceived as a second class citizen
Sorry for the late reply, all.
@kiffin - thanks for the coherent and well thought out response; here's mine:
"Sorry, but I disagree with your view that "even horribly mangled spaghetti code is a better starting point than nothing." I think that in that case it is better to start from scratch, e.g. back to the drawing board, rather than becoming victim to the quicksand."
Certainly, but if there's an *idea* there, you can certainly gain some footing and cover a lot of ground by at least taking a look at what the previous person has done, looking at what sucks horribly, and improving from there. At worst, you could probably at least write a small layer to make things look prettier while you work on un-fubaring the original code completely, most likely in the way you mentioned. We are certainly saying the same thing, I'm sure of it.
@systems I really can't say I agree 100% with you. Certainly, types of programmers are at the bottom rung of the ladder, but in essence I believe that developing and programming in their truest forms are nearly interchangeable terms. It's more about from which perspective you look at it, then you see the differences. All good practice stems from DRY and not re-inventing the wheel. It's just a matter of how much programming one is interested in doing. I could certainly take the slashdot code and have myself a threaded message forum, or the reddit code, etc., but I have decided I'm going to create my own that's tailor fitted to suit my needs. Why? I want to learn a few things, I have an interest in this kind of programming, and in my opinion, I could do it better. Others may disagree, but it's what's going to work for me. This doesn't apply to every case I encounter. I'm definitely not going to start creating an issue tracking system from scratch. Mainly because there are plenty out there, and I *don't* feel I could do it better in this case, with the time constraints I have at least.
I hope this helps to clarify my position. Thanks for the replies all.
@Devin,
Okay now i get it better that you were more focused on the difference between to type of coders.
One that it more pragmatic who connect and glue stuff, and another who is a bit more of a perfectionist who want things done right and don't mind building them from scratch
If you find my reply a bit deviating away from this, its because of the way i think, i alway tend to generalize things and take a top-down approach to thing, and well, i also tend to see the glass half empty
There are two things in life (of course there is more to life but i will focus on two) things to do, and things to be
Like if you always speak the truth, you might eventually end up being an honest person.
So putting this thought in perspective, do you really want to be a programmer or a developer, or just do development and do programming
The problem I see with being one or the other is that (and in reference to my previous post) it will become a discriminating factor and a social casting tool
As you yourself point out, sometimes its better to do development (glue stuff) and sometimes its better to do programming (build new stuff)
I hope you got me better now!