11 Replies - 866 Views - Last Post: 29 March 2013 - 12:54 PM

#1 Cyclopses  Icon User is offline

  • New D.I.C Head

Reputation: 5
  • View blog
  • Posts: 38
  • Joined: 20-January 11

Ready to work. Or was it?

Posted 27 March 2013 - 08:33 AM

Hey all,

Wanna talk about my current job position and the reason behind writing this post is actually,
because I can't seem to make the work, work.

Short background info, got hired ~5 months ago, and am working as Junior Software Engineer as my first real job.
I work besides school, retaining about 15 hours a week on-work locally.

Am working on the current biggest software we have.
It's a desktop CMS(content management system) piece for the medical branche, as in hospitals and psychologists.
Ran a sourcemonitor, one of the biggest solutions I work on has 3303 classes, within 65 individual projects.
There are a few other solutions with projects in them circling about 10-30.
Oh btw, these are Visual studio 2010 C# solutions.

So.. yea, it gives me a headache from time to time.
An off-topic question already raises as to what you think the size of the solutions feel like?

On-topic question is: As I am having trouble working with so many layers of hierarchical architectural structures.. does anyone have some tips as to how I can get my head in the game.
How can I get used to the code that's written by someone who's working here for about 8 years, that isn't well documented or commentated, and has this immense complex ocean (for me it is) of depth.

Small example currently happening at work, top-dev did a architectural change.
The change involved his higher-level classes to act differently (more virtual methods, different access modifiers).
And also involved a low-level class to override these methods, changing access modifiers inbetween and including extra methods / events and the like.
I have a low-level class just like his, but mine didn't get changed and stopped working completely, thus I have to fix it based on his.

It's rather difficult, not impossible.
But I quickly feel like I ain't developing enough, in the time I have.

So, any tips sirs? Madam?

Many regards and greets etc.

Me.

Is This A Good Question/Topic? 0
  • +

Replies To: Ready to work. Or was it?

#2 jon.kiparsky  Icon User is online

  • Pancakes!
  • member icon


Reputation: 7572
  • View blog
  • Posts: 12,722
  • Joined: 19-March 11

Re: Ready to work. Or was it?

Posted 27 March 2013 - 09:10 AM

Start by refactoring as much as possible and making the code self-documenting. Comment where necessary, make notes to guide yourself and others through the morass where you haven't cleaned it up, but prefer fixing the code to documenting it. Documentation is a time bomb: every change to the code puts the docs further out of date, and the most-used code is the code that changes the most. Therefore, the most-used code is the stuff for which the documentation is the most useless. If you can use tools like doxygen to auto-generate docs, that's great. Bake that into your build process.
Do you have a build process? Version control, issues list, deployment schedule, testing, and so forth? If not, you should institute those things. Basically, a sane environment requires that all changes come off of an issues list and are committed to a repository, builds are done on a regular basis and tested before deployment, and all commits are logged with at least the tracking number of the issue they address. Getting this in place means that at least you have a way to track how the environment is changing from here out, which allows you some hope of sanity.
Was This Post Helpful? 1
  • +
  • -

#3 Cyclopses  Icon User is offline

  • New D.I.C Head

Reputation: 5
  • View blog
  • Posts: 38
  • Joined: 20-January 11

Re: Ready to work. Or was it?

Posted 27 March 2013 - 09:29 AM

View Postjon.kiparsky, on 27 March 2013 - 05:10 PM, said:

Start by refactoring as much as possible and making the code self-documenting. Comment where necessary, make notes to guide yourself and others through the morass where you haven't cleaned it up, but prefer fixing the code to documenting it. Documentation is a time bomb: every change to the code puts the docs further out of date, and the most-used code is the code that changes the most...


Yea I'd like to give that a try, though my company puts extreme stress to something called "results first".
It basically means: Do whatever is needed, aslong as you can show us the design and use changes asap even if it means sacrificing code-design.
It might be what caused a mess in the first place, my colleague (aka, top-dev) stated today he can't put too much time into good design choices. Might be lack of work-force?

View Postjon.kiparsky, on 27 March 2013 - 05:10 PM, said:

If you can use tools like doxygen to auto-generate docs, that's great. Bake that into your build process.


I'll look it up! Might be worth a shot, it sounds good for starters..

View Postjon.kiparsky, on 27 March 2013 - 05:10 PM, said:

Do you have a build process? Version control, issues list, deployment schedule, testing, and so forth? If not, you should institute those things. Basically, a sane environment requires that all changes come off of an issues list and are committed to a repository, builds are done on a regular basis and tested before deployment, and all commits are logged with at least the tracking number of the issue they address. Getting this in place means that at least you have a way to track how the environment is changing from here out, which allows you some hope of sanity.


Yes sir. We got version control, issues lists and the bunch. (repositories, nightly builds, build versions.. about 80 test databases.. we develop certain parts of our software for individual clients, thus not every client has the same database)
However, what do you mean by deployment schedules? And would testing be "TDD" aka Test Driven Development?

Thanks for the help!
Was This Post Helpful? 0
  • +
  • -

#4 jon.kiparsky  Icon User is online

  • Pancakes!
  • member icon


Reputation: 7572
  • View blog
  • Posts: 12,722
  • Joined: 19-March 11

Re: Ready to work. Or was it?

Posted 27 March 2013 - 09:37 AM

TDD is great, if you're willing to commit to it and do it. But I'm talking more about testing everything that gets deployed to production before it's deployed - someone has to really try to break it, and that should be someone other than the developer who committed the change.

Quote

"results first".


Oy. Yeah, that's your problem right there. Just jam it in and get it working, and never mind if there's a better way... and pretty soon you can't move without breaking three other things. Well, the way to deal with that is to commit "results first" changes, but every time you make that sort of change, fix as much as you can in the files you touch. Even if it's just variable names and code layout, it's a help.
Was This Post Helpful? 1
  • +
  • -

#5 lordofduct  Icon User is offline

  • I'm a cheeseburger
  • member icon


Reputation: 2531
  • View blog
  • Posts: 4,631
  • Joined: 24-September 10

Re: Ready to work. Or was it?

Posted 27 March 2013 - 09:44 AM

Ugh, results first, the company I work for has been basically that for 30+ years.

Talk about nightmares.

And I do exactly what jon suggests. Every time I go to do something, I just lightly clean things up along the way. Thankfully I also have a lot of free time in my job to use just going in and ripping large parts out as well and refactoring them.

I'm telling you, I don't think anyone on this project knew what a class was.
Was This Post Helpful? 0
  • +
  • -

#6 Cyclopses  Icon User is offline

  • New D.I.C Head

Reputation: 5
  • View blog
  • Posts: 38
  • Joined: 20-January 11

Re: Ready to work. Or was it?

Posted 27 March 2013 - 01:39 PM

View Postlordofduct, on 27 March 2013 - 05:44 PM, said:

Thankfully I also have a lot of free time in my job to use just going in and ripping large parts out as well and refactoring them.


Now I'm gonna turn your Nightmare into Hell.
Since we have stand-ups every day, we must give feedback on the things we did.
Again, results first things are the kind of things that should be talked about.

Sooooo.. It really itches if stand there going "I refactored abit this morning, cleaned some code" while the rest goes on about the recent bug fixes they did and implementations they're planning/doing.
Makes you feel unworthy of the job when you don't have much to tell.
Was This Post Helpful? 0
  • +
  • -

#7 jon.kiparsky  Icon User is online

  • Pancakes!
  • member icon


Reputation: 7572
  • View blog
  • Posts: 12,722
  • Joined: 19-March 11

Re: Ready to work. Or was it?

Posted 27 March 2013 - 01:42 PM

Try "I fixed the crappy code you guys have been piling up so that your bug fixes stop breaking each other."
Was This Post Helpful? 0
  • +
  • -

#8 Cyclopses  Icon User is offline

  • New D.I.C Head

Reputation: 5
  • View blog
  • Posts: 38
  • Joined: 20-January 11

Re: Ready to work. Or was it?

Posted 27 March 2013 - 01:55 PM

Would love too! If their code wasn't insanely complex at some points..
Learned alot of stuff, am still only a student y'know, so fixing a near-30's programmer's code doesn't really sound all that, truthful xD.

Still, I might just give it a shot you know, will start with cleaning up the mess that gets left behind. Thanks for the pro-tip.
Was This Post Helpful? 0
  • +
  • -

#9 lordofduct  Icon User is offline

  • I'm a cheeseburger
  • member icon


Reputation: 2531
  • View blog
  • Posts: 4,631
  • Joined: 24-September 10

Re: Ready to work. Or was it?

Posted 27 March 2013 - 01:58 PM

I didn't rock the boat by calling anyone's code out as shit (unless the code was known to be from a coder long gone, and already made fun of in the office).

As my code refactoring and clean-up start showing their long term maintenance reduction effect, or make new implementation easier, and I hear someone say, "man, this or that is so much easier now". That's when I chime in, "yeah, thank standards I implemented for that one!"

Here's the thing...

If you're good, and your code reflects that, in due time people will recognize it. Make your own hoops to jump through, don't just jump through their hoops, especially if their hoops are counter-productive like "make it work" standards. (of course still do your job, they are the boss, just don't expect to make such a splash doing those tricks).

If they fire you for not doing enough to "make it work" and you don't survive long enough, or they don't understand the benefits of the refactoring you've done. Well, you probably wouldn't want to stay there that long anyway.

This post has been edited by lordofduct: 27 March 2013 - 02:01 PM

Was This Post Helpful? 1
  • +
  • -

#10 jon.kiparsky  Icon User is online

  • Pancakes!
  • member icon


Reputation: 7572
  • View blog
  • Posts: 12,722
  • Joined: 19-March 11

Re: Ready to work. Or was it?

Posted 27 March 2013 - 02:13 PM

Yes, thanks for clarifying that! Don't actually say "I fixed the crappy code you guys have been piling up so that your bug fixes stop breaking each other", ever. Say things nicely. So maybe "I saw that there was a conflict between this here and that there, so I rewrote this bit here, and now it's easier".
Was This Post Helpful? 0
  • +
  • -

#11 Cyclopses  Icon User is offline

  • New D.I.C Head

Reputation: 5
  • View blog
  • Posts: 38
  • Joined: 20-January 11

Re: Ready to work. Or was it?

Posted 28 March 2013 - 01:23 AM

Thanks for the contributions :)

You're right about making your own loops LordOfDuct, it's definitely something I should look more into.
Am currently adepting the code-styles from work onto my own code, simply becauses it reduces implementation time when working with the same set of functions/methods/subclasses.

I'll put all tips into motion and see how this ship will sail.

Thanks for taking the time.
Was This Post Helpful? 0
  • +
  • -

#12 Craig328  Icon User is offline

  • I make this look good
  • member icon

Reputation: 1912
  • View blog
  • Posts: 3,442
  • Joined: 13-January 08

Re: Ready to work. Or was it?

Posted 29 March 2013 - 12:54 PM

View Postlordofduct, on 27 March 2013 - 03:58 PM, said:

Here's the thing...

If you're good, and your code reflects that, in due time people will recognize it. Make your own hoops to jump through, don't just jump through their hoops, especially if their hoops are counter-productive like "make it work" standards. (of course still do your job, they are the boss, just don't expect to make such a splash doing those tricks).


I quoted that segment because it can't be repeated often enough. Anyone that writes code for a living has a decision to make: be a code monkey or be a professional. Professional means your standards should be well advanced from "just make it work". Making it work is a baseline product of our jobs. Making it work in an efficient fashion with clear logic, code notation and possibly documentation while reflecting best practices in the area of the coding universe in which you toil is being a professional.

By all mean, "make it work" is the first requirement. But past that, make it something you'd not be ashamed to discuss, explain and defend (if necessary) if someone brings it to the group.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1