The Joys Of Programming

FatConan wrote:

@Momgamer:

Ouch, that's a difficult one. I don't know if it's any help, but we went through something similar (on a smaller scale, but the same basic idea) a few years ago. The company was looking to expand from what was a small (almost bedroom-sized) operation, essentially revolving around the ideas and code of a couple of individuals, into a proper code-shop capable of handling multiple simultaneous projects and making bids on increasingly complex and worthwhile tenders. Of course the end goal and the current operation weren't exactly compatible. In the end, after much wrangling and hard work, they were able to implement proper project management, sensible processes and good Q.A., however, we lost some of the original individuals who weren't prepared to make the change to their M.O. to support what was required. Sounds like something similar is happening at your place and it may mean just waiting to see who takes it up and who bails on it.

Q.A. is especially hard if they've been working for a long time without it, you wind up with people suddenly being told they write buggy code (as they've done all along, it's what coders do) when previously they've believed it's been pristine (hell, every time they tried hitting F5 it all seemed well and dandy). It might be possible to sway everyone to see the benefits of proper processes and methodologies, but it'll be really hard if the cultures have previously been so different.

Good luck, it'll be worth it once it's done (although getting them to see that might not be easy).

Proper Q.A. can be rough to get used to. I went from a "Lets just get this released and we'll bugfix later" type place to an uber Q.A. "we must IV&V everything including your documentation" place. The transition was jarring, but ultimately for the best.

Ugh, there really is no way to deal with people like that other than to fire them if they won't train themselves and play ball. Besides, you're never supposed to keep management around when you merge. You keep the brains and knowledge base of the operation. You're probably going to have to be a hard ass and make the case to this guy's boss that he repeatedly defies or ignores your company's policies. It's really bad for culture to allow him to run amok.

Mixolyde wrote:

Ugh, there really is no way to deal with people like that other than to fire them if they won't train themselves and play ball. Besides, you're never supposed to keep management around when you merge. You keep the brains and knowledge base of the operation. You're probably going to have to be a hard ass and make the case to this guy's boss that he repeatedly defies or ignores your company's policies. It's really bad for culture to allow him to run amok.

Exactly what I was thinking, people are going to have to leave. When you have people reacting to everyone else just doing their job as if it were a personal attack, there are issues going on there that you can't solve. He either needs to get his own house in order or move on.

I realize it's not that easy, but you're either going to have to marginalize him or get rid of him, somehow. There will probably be some other people that leave when it finally becomes apparent that the "old way" isn't going to fly anymore. People get very attached to certain ways of doing things.

momgamer wrote:

But maybe you guys can help me.

Now I'm standing gingerly in the footprints of that senior, and I'm having a very hard slog trying to interface with these guys we inherited from our company merger who have never worked for anything bigger than a mom-and-pop shop with one or two script-kiddies who call themselves programmers.

They think that 2000 hits a week is a huge load (some of our sites do that much in a minute), they don't use server-side anything unless forced, and they don't track their bugs or do design documents, and they use 1-letter variable names all over the place. They just don't understand there's a reason for stuff like communication, comments and documentation. And they've been handed the task of doing a look-and-feel upgrade to one of our projects.

Do you have a performance testing suite/team? The most expedient way to communicate to these guys that their technical approach isn't appropriate is for them to watch it fail spectacularly (at no risk to your actual business). The other stuff is largely business culture. If you want design docs, all you can do is refuse to accept code or whatever that hasn't been done according to process. Set artificially early deadlines to account for the fact that you'll be rejecting their submission and then waiting for them to write a doc, fix their code to be readable, whatever. Eventually they'll either come around or you'll have enough grounds to let them go. It isn't a personal thing if you apply the same rules to everyone.

Document. Everything. You. Do. Momgamer.
CYA first, so you can show you weren't being combative, you were simply following established corporate and legal procedures.

As we rednecks say, you cain't fix stoopid.

Yes, there's an 'i' in it when pronounced juuust right.

FatConan wrote:

I've never been 100% convinced about the effectiveness of code reviews

I have. When I worked for a place with lots of good coders, it was an excellent way to learn from people who had been doing this for a lot longer than I had.

When I moved to a place filled with mainly not-so-good coders, it was a way for me to communicate to teams that the slack times were over and sh*tty code wasn't going to be tolerated any longer. After a couple of sessions publicly (but politely) tearing down n-squared functions that should be log-n functions (or whatever), there was usually a miraculous and very obvious split between those people who found the ability to start writing solid code, and those who would rather play political games to try to recapture the good ol' days when no one was critiquing their stuff.

Those who remained eventually learned that writing things in an un-lazy fashion doesn't actually take all that much more time than just hacking, and the code reviews for experienced devs moved to earlier and earlier in the process, until they were just design discussions. This scenario played out several times over a few years, and only once did I ever have to maintain those awful line-by-line complete reviews for more than a few months, and that was for a team full of sullen, repurposed mainframe programmers that was beyond all hope of redemption.

I totally agree with you, but it's important to recognise what code reviews do and don't give you. They aren't free testing. Unless you spend a very great deal of time on them, the only kinds of algorithm issues you'll find are howlers. Subtle bugs still won't be found until you test the code.

My place has very time-limited projects, and they've been trying to use code reviews as poor man's class testing, which only works in the most egregious cases.

Even then, you can sometimes find a bit of a microcosm in the team where the numpties can review each other's code, and then you have to have a review rota or something.

DudleySmith wrote:

I totally agree with you, but it's important to recognise what code reviews do and don't give you. They aren't free testing. Unless you spend a very great deal of time on them, the only kinds of algorithm issues you'll find are howlers. Subtle bugs still won't be found until you test the code.

This was the point I was trying to make, only Dudley here does it far more eloquently and succinctly than I managed :).

I've used code reviews pretty much everywhere I've been able to implement them. They have a lot of drawbacks but the positives outweigh the negatives, from my experience. They are not substitutes for testing and they can become a general waste of time quite easily if dev management does not keep track of them.

On the other hand, they are invaluable for increasing the general competence of the developers. In my experience, most devs *want* to write decent code, they just have *no idea* how to go about doing it. Having someone with more experience look through the code and "suggest" alternative methods of implementing something means the reviewee will learn something. If they cannot, then other means to get them up to speed need to be looked at.

Code reviews, properly run, also engender code ownership throughout the team, which I think is important for long-term success of a project. Everyone should feel like they own all the code; code reviews help out with that.

Finally, code reviews are excellent ways to insure that the desired architecture/design is being implemented in the manner in which the architect/designer has envisioned. Granted, there are other methods of doing this, but a code review makes public the intent behind any specification that may have been written. Other devs see the feedback and can adjust their implementations as well. Granted, this does not work if the architect/designer lives in an ivory tower and can not or will not be part of the review process. In that case, other means have to be taken to insure that the "vision" is being implemented correctly.

I am absolutely not arguing with any of that, and I passionately argued for code reviews when I joined my current company.

I was merely listing some of the ways they can give you less value than you might expect.

Yeah, there's no silver bullet to this stuff. Bright people, good process, smart management, great ideas: then, if you are lucky, you have a chance.

Tough business.

I am not sure how you mean "have a chance" but in my years as a programmer, code quality has not proven to be an accurate indicater of business success... in fact, it seems to bear almost no impact. Or if it does, it is orders of magnitude less significant than sales and even marketing.

Frustrating and even scary, but the best codebase I worked on disappeared because someone didn't pay the IRS, while disgusting aberrations survive and even proliferate, never to be refactored because new customer X wants new features A B and C. Besides, that other thing is "working fine, so why waste time on it? "

Sorry to be so cynical, but I'm working on my third "just duct tape it and I promise we'll fix it after crunch" in the last year.
But, hey, sales are up, so there's that.

Am I the only one that ebbs and flows between "hey, get better at what you currently use" and "hey, learn a new technology soon before you have to create another web app in PHP"?

I say this because, altho I barely got started before, now I'm a little further in learning RoR. Haven't done any coding tonight, but after 4 chapters of Eloquent Ruby (which I selected on a total whim), I'm hooked. I didn't know that a) a book like this exists where I don't have to sit in front of a computer to learn from it and b) that I would find so much (and I mean a lot) to love about it.

Eloquent Ruby is an excellent book. It's also a pretty new book - it's only a few months old.

Ruby really has a lot of good books. I still have a soft spot for The Ruby Programming Language simply because it was patterned after The C Programming Language (aka "K&R"). Maybe not a comprehensive as "The Pickaxe Book" but lean and no-nonsense. But Eloquent Ruby is one of those special books that teaches you not only the language, but the idiomatic style.

Am I the only one that ebbs and flows between "hey, get better at what you currently use" and "hey, learn a new technology soon before you have to create another web app in PHP"?

Oh god. If ebbing means more PHP, then flow. Flow f*cker flow!

*Legion* wrote:

Oh god. If ebbing means more PHP, then flow. Flow f*cker flow!

Heh. Being the senior developer for a web app that's over 6 years old has it's drawbacks. But, being the sysadmin/lead IT has it's benefits.

It won't be long (I hope) before I start making Git and RoR a mandatory part of working in development.

trueheart78 wrote:

It won't be long (I hope) before I start making Git and RoR a mandatory part of working in development.

Yeah! And make everyone use Vim too!

*Legion* wrote:
trueheart78 wrote:

It won't be long (I hope) before I start making Git and RoR a mandatory part of working in development.

Yeah! And make everyone use Vim too! :twisted:

I think you may have misused that emoticon.

I've been reading up on the Heroku site as to what all is available, above and beyond the free cloud instance. Gee, I wonder where I'm going to run my first real RoR app...

Any other RoR cloud services out there that come highly recommended?

The startup job I turned down was running on AWS. I'll give Heroku a recommendation for small, free apps or testing. I recently rebuilt my anonymous secrets site in Sinatra/Padrino, and moved it to Heroku from ASmallOrange. Pretty happy so far.

Bonus_Eruptus wrote:

The startup job I turned down was running on AWS. I'll give Heroku a recommendation for small, free apps or testing. I recently rebuilt my anonymous secrets site in Sinatra/Padrino, and moved it to Heroku from ASmallOrange. Pretty happy so far.

So why did you move? And what type of system did you move to (VPS, etc) ?

trueheart78 wrote:
Bonus_Eruptus wrote:

The startup job I turned down was running on AWS. I'll give Heroku a recommendation for small, free apps or testing. I recently rebuilt my anonymous secrets site in Sinatra/Padrino, and moved it to Heroku from ASmallOrange. Pretty happy so far.

So why did you move? And what type of system did you move to (VPS, etc) ?

I had been running a friend's site, and piggybacking on her plan to run my site. She wasn't looking forward to spending another $50 on hosting for the year, so I took *Legion*'s advice and moved her to NearlyFreeSpeech.net for $1.22/year. Needed a place to put my site, and Heroku was free, so I went with them.

I don't think NFS is VPS, but I have no idea how I'd tell, anyway. cd-ing to '/' only shows my stuff, so it may actually be a VPS. I definitely like only paying for what I use, and for static sites or PHP, it's hard to beat 1-2 cents/day.

Bonus_Eruptus wrote:
trueheart78 wrote:
Bonus_Eruptus wrote:

The startup job I turned down was running on AWS. I'll give Heroku a recommendation for small, free apps or testing. I recently rebuilt my anonymous secrets site in Sinatra/Padrino, and moved it to Heroku from ASmallOrange. Pretty happy so far.

So why did you move? And what type of system did you move to (VPS, etc) ?

I had been running a friend's site, and piggybacking on her plan to run my site. She wasn't looking forward to spending another $50 on hosting for the year, so I took *Legion*'s advice and moved her to NearlyFreeSpeech.net for $1.22/year. Needed a place to put my site, and Heroku was free, so I went with them.

I don't think NFS is VPS, but I have no idea how I'd tell, anyway. cd-ing to '/' only shows my stuff, so it may actually be a VPS. I definitely like only paying for what I use, and for static sites or PHP, it's hard to beat 1-2 cents/day.

NFS != ASmallOrange. So now I'm confused...

Sorry for the confusion. Both sites used to be hosted on ASmallOrange's shared hosting for $50/year. I moved my friend's static site to NearlyFreeSpeech for $1.22/year. I moved my Rails/Django/Sinatra/Padrino site to Heroku for free.

*Legion* wrote:
trueheart78 wrote:

It won't be long (I hope) before I start making Git and RoR a mandatory part of working in development.

Yeah! And make everyone use Vim too! :twisted:

It's rough enough trying to learn another language. Any tips for Vim usage? Cuz I've yet to become a fan, and you might not get another chance. The way I live, I could be using emacs soon...

trueheart78 wrote:
*Legion* wrote:
trueheart78 wrote:

It won't be long (I hope) before I start making Git and RoR a mandatory part of working in development.

Yeah! And make everyone use Vim too! :twisted:

It's rough enough trying to learn another language. Any tips for Vim usage? Cuz I've yet to become a fan, and you might not get another chance. The way I live, I could be using emacs soon...

Learn VIM Progressively
Coming Home to VIM

The second one made me fall in love with it as an editor.

I like vim, but I still use idle for my pythonic adventures.

All I'll say about vi is that grokking the beauty of the following key sequence is a step on the path to enlightenment:

{!}fmt

Note, however, that I use emacs and vi in about equal amounts. Emacs for long-running editing sessions when I have a bajillion things open at once, and for running my mail reader. vi for quick dip "edit this file and begone" situations.

In other news: I just discovered that flask is a pretty solid looking Python web framework. Doesn't have too much baggage. Isn't so slim that you need to pull in 15 dependencies for hello world. Has an overall design aesthetic that matches my "cleanliness = godliness" API sense. Now I just need a project to really push it with (I have a work project I'll probably be using it for, but it's not going to do anything that interesting.)

I still have my half-written series of blog posts on learning Vim to finish.

*Legion* wrote:

I still have my half-written series of blog posts on learning Vim to finish. :(

Yeah, I'm still waiting on those. Get to it.

If you do any non-Windows development at all, learn at least enough VI or Vim to be productive. It's preinstalled basically everywhere, while emacs is not. Then also find some editor that runs on all your platforms of choice that you absolutely love and become an expert with it.

Git is great but it makes many rather common tasks surprisingly difficult and/or awkward (at least to me anyway): reverting changes, the equivalent of "svn blame", not spamming commit logs with merges generated from "git pull", etc. Maybe one of these days I'll try Mercurial...