“I want to code the site using PHP and a bit of Javascript, but my skills with these are not exactly up to the job yet.”
You must understand that you need to learn 2 separate things and you need to learn them well.
For javascript on the client you need nothing other than the browser you already have and the Rhino book:
http://www.amazon.com/JavaScript-Definitive-Guide-David-Flan…
Learn what’s in this book! Go through all the exercises and tutorials. Build something. You can augment the book with tutorials you find on-line. Then you can View Source on any web page and understand what they did (and what they did wrong).
On the server you will have to find any common LAMP stack and load in onto your machine. The execises and tutorials for php, MySQL, and apache should be enough, although you can find more almost anywhere. Build something! Now that you already know javascript, you can include that in the pages you build as required.
Only after you have a solid understanding of the basics of these 2 technologies should you consider a framework. This can be tricky. If you adopt a framework too soon, you may run into a problem for which you don’t understand enough about what’s going on under the hood because you never learned it. If you adopt a framework too late, you’ll be hand coding everything and will never get done.
Most importantly: you can only learn any of this by doing. Time consuming doing. Books and resources any necessary but hardly sufficient.
Do not fall into the trap of only learning at the surface and expecting to find someone else to do the coding. This does not work for a small software start-up. You must dig deep and learn well.
I love email. Why? Because I’m a programmer and I don’t want to be interrupted. I like to keep the day-to-day things simple because my work is anything but simple.
I use gmail and everyone I know has my gmail address. It has excellent spam filters and it’s easy to manage. Best of all, it never bothers me. When I’m ready for a break, I check and manage my email. It takes 5 minutes, just enough time to eat an apple.
Family, close friends, and some business associates have my cell phone #. They know not to text me because if I’m working, I will not respond. If I’m not working, the only response they’ll get is “ok”. If the phone rings, I know it must be important to talk. Usually not for long, then back to work.
I do not IM. I can’t imagine worse ways to ruin productivity. I IM’d for 3 days. I got nothing done, so I emailed everyone to never IM me again. Email me and I’ll respond when I’m available.
I surf my favorite sites during breaks. When the break is over, on go the headphones and up comes my text editor. See you in an hour or two. Not before then.
When it comes to maintaining code, I believe there are 2 kinds of crap: subjective (I don’t like it) and objective (it’s crap because of these 14 specific reasons).
You’re probably right about people who inherit my code. I know, when they’ve whined about it, I confronted them. “Please show me exactly what’s wrong with it. What are your specific complaints about violations?” I rarely got an objective answer. It was usually something about formatting, indenting, variable names too long, variable names too short, I’m used to it the way we did it (wrongly) at XYZ Co., something like that.
True crap can be objectively identified by a violation such as:
- variables named so that no one except King Tut could possibly figure out what they are
- the same variables used for different purpose “at the same time”, usually in nested recursions
- variables named with 1 or 2 characters
- unassigned variables
- variables initiated when they shouldn’t be
- division by zero
- single entry, multiple exit (heavily maintained so that now outlying cases skip critical logic)
- the same code in multiple places (only some of it maintained so that outlying cases skip critical logic)
- endless recursions (for outlying cases only, naturally)
- comments that don’t agree with the code
- data base tables with no definitions either in the schema or any code (my new favorite)
I could go on and on, but you kinda get the picture. I wonder how many readers here have posted crap like this on their “wall of shame” at one time or another. It’s funny the first 2^n times. Not so much fun anymore.
“Software Engineering is Dead” is obviously an overly sensational title, but let’s look for the deeper truths.
First a little background. I have built a career developing business applications as a contractor, often in very large organizations. I am almost always very successful and I’m often regarded as a hero doing what most people here would call “just doing my job”.
Why is it so easy to be a hero in the enterprise with software that would just seem ordinary in other places? Is it because enterprise programmers aren’t as good as us? Is it because their managers are all phbs? Or because they don’t know how to run projects?
I’d say no to all of the above. Enterprises are filled with lots of excellent people doing great work.
I think that the real problem is that the Systems Development Life Cycle (SDLC) that so many depend on so much “never really did work”. Why?
Every phase depends upon Phase I, Analysis to be rigorously done. This rarely happens for 2 reasons: users often don’t know what they want and most systems analysts don’t know how to extract it even if they did.
So almost everything done after Phase I is built upon a foundation of sand. It’s either wrong or sinking fast.
And what do most people do? Everything except fixing the problem: more resources, more project management, freezing specs (which aren’t right in the first place), more rigorous deadlines, etc.
But rarely does anyone attack the core problem with the Systems Development Life Cycle: defining the expected result.
So what should we really do? Develop something, anything, quickly, cheaply, and get it out to the right users. They will instantly give you feedback. What’s right, what’s wrong, what’s stupid, all the cool stuff that no one thought of.
No one can just sit down and write a Functional Specification for a large business application. And even if they could, you don’t want them spending time on it. Better to get the right people together and find out what they need. Usually, no one of them knows what the result should be, but all together, any decent developer should be able to extract enough data to write version 1.0 of “something”.
It’s a lot easier to judge something that exists than define something that doesn’t.
The larger the organization, the more difficult it is to change their ways.
Software engineering isn’t dead. It’s just that the process of depending upon blueprints before you get started never worked in the first place.
“Their service has more bells and whistles, but mine is much simpler and quicker to use.”
You just answered your own question. You must focus your marketing on “simpler and quicker” to the exclusion of everything else. (Either “simpler” or “quicker” would be even better, focusing on “one” thing.)
Jack Trout, in “Differentiate of Die,” says it much better than me:
“The best way to really enter minds that hate complexity and confusion is to oversimplify your message. The lesson here is not to try to tell your entire story. Just focus on one powerful differentiating idea and drive it into the mind. That sudden hunch, that creative leap of the mind that “sees” in a flash how to solve a problem in a simple way, is something quite different from general intelligence. If there’s any trick to finding that simple set of words, it’s one of being ruthless about how you edit the story you want to tell. Anything that others could claim just as well as you can, eliminate. Anything that requires a complex analysis to prove, forget. Anything that doesn’t fit with your customers’ perceptions, avoid.”
“Instead of students studying Literature, Art, History, and Science they would be going through the motions of a scholar while occupying their minds with things that formerly had been learned at a desk as an apprentice in a dreary Victorian counting house.”
That may be the best description of the concerns of the MBA I’ve ever read.
I have my MBA and, to this day, I still don’t know how I feel about it. Sure, it covered a lot of valuable theory and it’s opened doors, but then again I often wonder if the time would have been better spent in industry, honing my skills in the trenches.
If you “really love her”, then you already oughta know what’s most important. (Most important, not the only thing.)
Her “expectations” are not really expectations. They are cries for help. Listen.
Some of the things we have done:
-We take French lessons “together” and speak French around the house all the time.
-We always eat dinner together.
-We go out somewhere every weekend (usually not my pick).
-We catch up by phone several times a day.
It’s hard to explain, but I have a “more balanced lifestyle” “without” “lower expectations”. You “can” have both. It’s up to you to find a way.
[EDIT: Forgot one of the most important things: Sunday brunch is a big deal at our house. We shop together (the night before), cook together, and sit together for 2 to 3 hours at a table full of great food and 3 newspapers. At first, I thought it was a waste of time, but now I really look forward to it.]
“Hardware is cheap, programmers are expensive.”
“Mediocre” programmers are expensive.
Good programmers are the bargain of the century.
If companies would just wise up enough to pay a good programmer 3 times as much as a mediocre programmer to do 10 times the work, do it right, and do it so that it can be maintained reasonably, any tradeoff would become moot. But companies generally don’t do this, which is probably one of the main reasons the best programmers go off and do their own.
Great question. Ask it to n programmers and get n^2 responses. This could easily be the subject for another post or even a book. Just off the top of my head in no particular order:
- understands the problem at hand before writing any code
- uses the right tool for the right job
- follows accepted standards and protocols without sacrificing creativity
- names variables & functions what they actually are for the next programmer
- anticipates what could go wrong before relying on a debugger or testing
- understands the underlying architecture and how to best utilitze it
- never writes the same code twice
- never writes in 150 lines that which could be written in 100 lines
- Poor code: uncommented. Mediocre: commented. Good: doesn't need comments.
- understands the entire code life cycle & writes it to last
- has pity on the poor soul who has to maintain it & leaves a clue or 2
- writes flexibly enough to be easily changed before the project is done
I could go on and on, but you get the idea. In general…
A good programmer writes it right, once, in a week.
A mediocre programmer writes it OK, in 2 months, and then futzes with it forever.
A bad programmer never gets it done.
I have 2 signs above my desk.
One says, “It doesn’t matter”. This is for when I get so stressed out, I have trouble doing anything. It helps keep things in perspective.
The other says, “Jabez Wolffe”. His guide boat forced him to abandon his swim across the English Channel because they couldn’t see through the darkness and fog, and it was too dangerous to continue. What they didn’t realize was that they were only 100 yards from shore, but they had no way of knowing.
How far from shore are you?
I would suggest doing whatever you can to find out before making any decision.