[sharkeyph]

Hello all,

So I have been developing for about a year and a half now and I have a self assessment to complete. Part of the assessment is focused around goals and accomplishments that I want to achieve over the next 6 month to a year.

I am comfortable with the technologies and languages we are using at my work and the code I produce is up to par with what is expected of me. My main issue in my career is not the quality of my code, but how I am engineering. For example, I can code for a case, but have hard time coding it in an abstract way so it can be reused by other parts of the system for the same use case. Let me say here that I am a self taught programmer with very little college experience.

My question to you guys is 'How can I take my desires stated above and articulate that into deliverables / goals?'

I don't really want to read another 'Write a program in X language in 24 hours' or deal with anything that is concentrating on a specific language. My purpose here is to provide a way for me to grow as an engineer, not necessarily a programmer. (Not sure if that makes sense )

[NathanMullenax]

It's good that you want to generalize patterns you code over and over again, if that's the case. The problem is (at least in my experience) that one must justify this expenditure of time in terms of short term planning--this is especially true in 'extreme' or 'agile' (or whatever the buzzword may be) development.

My experience is in web development, and I've had the luxury of doing such 'generalizing' projects on occasion, but it really does take a couple of use cases to even formulate a good generalization.

Example: I was writing essentially the same user authentication code over and over again, or worse, fixing several different variations on the roughly the same authentication code written by different people. Worse still, several other people had tried to generalize the authentication process as well. It turns out the use case was a moving target, and accordingly the authentication system in practice was convoluted and crufty.

I guess what I'm saying is, sometimes it is actually better to bang out X than to try to solve all instances of X in one go; one can easily end up on the other end of the premature-generalization rabbit hole. On the other hand, I think there is tendency (at least in web development) to view a piece of software as pile of features. As this pile accumulates, the code base becomes increasingly difficult to manage and development slows down. What you're left with is a semi-functional prototype instead of a completed software product.

Geez. I didn't think this was going to end up sounding like a rant. In my opinion, you should definitely try to work developing appropriate higher-level abstractions for things you use a lot into your 'goals' section. But, I would avoid doing things like programming a 'multiple site-hosting configurable self-assessment and planning tool' that no one will know how to use nor be able to maintain (my bad).

This post has been edited by NathanMullenax: 24 January 2013 - 08:21 PM

[tlhIn`toq]

Quote

My purpose here is to provide a way for me to grow as an engineer, not necessarily a programmer.

Whiteboards and Legos.

More time planning tends to be advice that can't be given enough. Most people I see sit back in their chair, stare at the ceiling for five minutes then start banging on the keyboard.

Next is the guy that spends half a day at the whiteboard working out the one program. Then building it.

Rare is the guy that spends 5 days at the whiteboard working out the program... then envisioning the next set of features the boss hasn't even asked for yet... Then seeing a way to break down 75% of the code into a reusable library or GUI controls into reusable pieces.

You have to step back and see the big picture. See the forest and not a couple trees.

Nathan is right when he says it takes more time. But it takes more time up front while saving time down stream. As you build a program and you realize "I've written this same code to do xyz before - 5 times before - in every program I create", then take a moment and put it in a reusable library project.

If you take the added 5 minutes on each Lego block of code to make it generic and follow the rules of 'black box' coding with no side effects you will build up a library of reusable code. Once you have those tools at your disposal, like a bucket of Legos, you will start seeing how you can snap a few ready-made peices together with just 5 lines of wiring and bam you're done with that module.

This post has been edited by tlhIn`toq: 27 January 2013 - 07:17 PM

[Lemur]

I've been asked before how in the world I write extensible code being fresh out of College, how it just works, and how clear it tends to be. Now how the devil do I do that? My coding skills are perhaps above average at best, I don't have an extensive knowledge of algorithms, and I only have one year of professional experience in a field that isn't even entirely development.

Here's exactly what I did last time I had a huge project, and be warned that I will snip all relevant details about what it is as per the privacy of my employer.

I got out a sketch book, a non-photo blue pencil, various rules, pens, and mechanical pencils. I had a few legal tablets out as well, and a full white board. My boss asked me a few times why I hadn't started on coding yet and I told him that it would be well worth it. I get back to the office and start playing a collection of Chopin's Nocturnes, good classical music is always nice to have. I planned, analyzed, gathered every detail and modeled every possible data point I could come up with. Every little detail needed to be found and mulled over. Everything.

I spent 3 days like this of solid planning before I even started psuedocode. On the 4th day I started to code, Ruby. I was done within the day, completely starting from scratch. This was an extensive library for automation, and I was able to add completely unknown equipment to the library in a matter of minutes.

I planned and abstracted until the solution was clear and apparent, and it served me abundantly well.

My number one rule is that I will not touch code until it is absolutely the right time. Do note that I won't hold to that for quick scripts and checks, that would be idiotic. Get a good feel for the right amount of planning and get good enough and you'll go miles beyond any other coders.