New job - big project - where do I start

spags

I just recently started as a PHP developer, with about 1.5 years part time experience. The project I am assigned to do is work on a company website and intranet... the guys who did it before have many "concoctions" of doing things that ... are.. hard to understand. Comments in the code are few and then, reduntant. Include files appear ANYWHERE and functions are rare... huge if/else statements are everywhere.

They have the site so it redraws every graphic ... because they want the flexibility to be able to change the website colors at any given moment by changing a few numbers...possibily in the future a user can choose their own colors. Its an information site for employees??? I don't think its necessary at all..too slow, complicated, I don't understand what the facination is.

I made ER diagrams for the databases because they didn't have any. And, even the databases are hard to follow because they are not correct since they do not have very good constraints.

Part of this is just venting 🙂 hopefully someone will understand... and... how do I go about implementing changes without making the guys who made the current system mad? They were happy that I made the ER diagrams and some of the functions I made they thought were handy. But, they are not quick to change anything major.

So if anyone has some suggustions on where to start ... I'd appreciate it 🙂

Thanks
Spags

toma42

I'm a dick. I tell people when they screwed up and I point right to their problem and tell them they should have done it this way. I ask them why did they do this when doing it my way is right?

Yes, I do still have a job. I worked at a .com for a few months where there was terrible code and I would practice the above questioning regularly. I eventually had the respect of a LOT of the developers because they saw that I knew what I was talking about. (I too made db diagrams and taught management what they were) I was met with less than helpful answers at first because people don't like being told what to do even if they're doing it wrong, but eventually I was understood as one of the best php programmers there. I quit that job for many reasons...partly because management did nothing to stop the tsunami of bad code written daily that I couldn't stop.

Anyway, I'm not advocating quitting your job. I suggest you show the developers the right way to do it or just sit them down and start questioning why is it done this way. I've become pretty good at manipulating people to say, oh, yea, your way looks great...so hold your ground, but let the bad coders think they had a hand in deciding the right way to rewrite the code...it'll keep them happy (even though you'll know you manipulated their thoughts totally and your way from the start was the way you eventually used.)

knickerlas

Hi,
I don't work in the industry but the concepts are the same whatever the field.
I whole heartedly agree with Tom. I think the very best skill anyone that has to play 'office politics' can learn is the ability to let people feel they had a hand in the decision making process whilst taking a healthy proportion of credit for your hard work.
Think about it in these terms.
The secretary at an office has by alot of peoples reasoning an unimpotant position and most don't pay much attention to them. A clever guy knows that this is the individual that passes on his calls, writes his letters, prioritizes the work they have from all the other people that use her services. If she feels that you value her (or his!) opinion and value there work they'll not only work there arse off for you but sing your praises to everyone else.
Make your developers feel important and valued and let them 'help' you recode their bodged jobs and take all the credit!

Good luck

Nick

mdmann

I agree with the comments Tom and Nick made
as well, but I also think you have to be
aware that sometimes people just aren't
given the chance to produce the most
efficient code the first time around. Pro-
ducing efficient code takes planning, and as
more and more pressure is created to get
things done fast so as not to be scooped
by the "competition," sometimes the
pre-project planning suffers.

I'm not trying to be an apologist for the
other coders in your organization, but it
may be that when this project first started,
there was a rush to get things done quickly,
and not necessarily smartly. On the project
that I am currently working on, there was a
big push to get something working as soon as
possible, even though I had never done any
web-publishing or PHP coding in my life,
the project was ill-defined, and I was (and
still am) the only person doing the coding.
I was able to provide something that has been
regarded very favorably by a couple levels of
management, but I know that the code is
not optimized and needs to be cleaned up.
And I try to do that whenever I get a moment
of breathing time (I'm the only person
working on this project). The originators of
the code you are working on may have had a
similar situation to deal with, may have
always intended to go back and clean things
up, and may have been sidetracked onto other
things.

I guess what I'm saying is don't use the
glass house approach unless you know for
sure that these are just sloppy people who
don't know what their doing, rather than
good coders who may have had to deal with a
less-than-perfect coding environment.

Michael