[Craig328]

Mastermind_13, on 13 June 2010 - 03:42 PM, said:

@ Craig 328, I agree Respect isn't something you automatically give, psychoCoder, clearly knows & understands what he is talking about! I have had well over 100's of contracts to FIX issues that other programmers have botched up because they have HELP from other people & don't really understand what they're doing. From my experience If you need help, it shows that you don't understand your stuff. You either have it or don't! I do agree that age doesn't play a big part, but maturity does! I know how developers work, because I have had to fix what they mess up. It just bothers me to see someone talking about something that they don't know too much about. Every contract is different mind you so experience is key! And mistake me if I am wrong you have the tone that if you get it working you're pretty happy. I don't! I work very hard!

Well, I won't belabor the notion that what impresses and elicits respect from one person does not automatically extend to all people. As I said, I'm sure there are people on these forums who are quite accomplished and perhaps even expert in what they do. To someone with a few years experience such as yourself I'm sure that inspires a fair degree of impressed respect at their skills. It doesn't however necessarily generate the same response in others.

As for my tone, well (and I'm sure you'll appreciate this) I speak from the perspective of being a contractor, an employee, a junior dev, a senior dev and a lead dev with around 12 years experience. I've worked for small shops, big firms and pretty much everywhere in between. What I said earlier about how "getting it working" is sometimes the rule you have to follow as a dev wasn't the result of theoretical musings or mental rumination. It's the result of having been there and done that...and the situation is quite common.

In fact, let me share an insight with you that I'll bet you'll find surprising: it's been my experience that high-volume contractors don't tend to produce the best code product for their clients. I've seen many examples of code produced in the absence of a real understanding of the business rules it's meant to serve, code produced that was obviously cut, pasted and modified from a previous effort to fit the existing need, and code that, quite frankly, was made to work in the circumstances specified by the contract but little further and that since the contractor wasn't going to be there to deal with it afterward...well...it "works well enough".

As for "From my experience If you need help, it shows that you don't understand your stuff"...well, I'm sorry but that's simply not true. Nobody knows everything and the next person who tells you they do is full of sh*t. Even the most qualified people in a field will tell you they don't know everything. In fact, without people knowing everything there'd be no innovation in the world. I've worked with my chosen language for well over a decade and I can assure you, I don't know everything there is to know about it. I still consult docs, books, guides and my colleagues regularly. There is no prize for claiming you "know it all" and failing that does not equate to "you don't understand your stuff". It's ironic you mentioned maturity because the comments you made suggest you may have a little ways to go to nail that down.

I don't like to criticize blindly but...dude...you're 21 whole years old and have been doing what you do for 4 whole years. I'm pretty sure your 4 years (and "100's of contracts") have been very interesting but over the past 4 years I've worked somewhere in the neighborhood of 9000 hours or so and have been paid well for the vast majority of them. My tone comes from experience so when you say "experience is key"...yeah...I know.

So, I'll just repeat what I said earlier: most developers would LIKE to produce clean, simple, sublime, well-vetted code but the world often dictates that they have time enough to write it to a certain performance standard before they are moved to another project. The fault isn't theirs' usually. Many times it's the demands of the company they work for that does this. It's not always a commentary on their skillset but more normally the environment in which they exercise it.

This post has been edited by Craig328: 13 June 2010 - 06:15 PM

[William_Wilson]

Craig328, on 13 June 2010 - 08:13 PM, said:

... most developers would LIKE to produce clean, simple, sublime, well-vetted code but the world often dictates that they have time enough to write it to a certain performance standard before they are moved to another project. The fault isn't theirs' usually. Many times it's the demands of the company they work for that does this. It's not always a commentary on their skillset but more normally the environment in which they exercise it.

Absolutely perfect.

Honestly, I don't see anything wrong with using the getting it done approach as a first step. Having something to use for initial testing of a system can help a team be more efficient and productive. That said, the code written in that respect should ideally never make it to release, but we don't live in an ideal world.

The biggest issue with this that I've experienced, is half way programmers may meet the standards a company's timelines allow for, making being a superior programmer of no importance. If doing it RIGHT was what programmers were hired/fired by, a whole lot of people (including some friends of mine) would be jobless real soon. Fortunately for them, they are just good enough to get things done and no one needs to know they can't do any better.

[cfoley]

When getting something working the right way, make sure you don't over complicate or over generalize things. I did that for years and ended up finishing approximately nothing. If you are writing a throwaway script, the happy path is exactly the style to go for.

By all means, organize your code so it is easy to add features. But don't add them yet! You have no idea how much time I have spent maintaining methods that are never called just because I think "a proper list should have a method to remove items" or something. These days, I don't include so much as a single setter which is never called by my program. It's trivial to add and I can do without worrying about weather it should do bounds checking (or whatever) until I need it.

[PsychoCoder]

Hey diego_pmc think it's weird that you're the only one who downvoted the first post in this thread? Like maybe it has something to do with what was said in the pirate bay thread, because I know it cannot be from the initial post in this thread.

[Craig328]

PsychoCoder, on 22 June 2010 - 07:26 AM, said:

Hey diego_pmc think it's weird that you're the only one who downvoted the first post in this thread? Like maybe it has something to do with what was said in the pirate bay thread, because I know it cannot be from the initial post in this thread.

I'll just leave this here...



I had one to burn so I re-balanced it for ya.

[Edit: Now that I think on it...I wish I had teh Ph0tosh0pz so's I could take out that "K". Wonder if I could getz it fr0m PirateBay...]

This post has been edited by Craig328: 22 June 2010 - 09:23 AM

[JackOfAllTrades]

Good example of how this works in the real world. I've been working on an integral piece of our product which is a real pain in the ass. I put in a bunch of sanity checks for a certain function. A co-worker has started integrating his part with what I did, and began running into trouble with the sanity checks, so...the sanity checks have been removed. Why? Because of deadlines, and we MUST hand this off to QA according to the schedule, so therefore...it just must work well enough to get into QA. THEN maybe we can iron out the kinks.

The real world: it sucks hairy llama ass.