286
k33da
66d

On point.....

Comments
  • 5
    While this is true, people don't get that since most of us are paid not for the years of experience but time. It's an odd perception but people would gladly pay your wanted amount if you would take a long time to fix the issue, rather than a quick solution.

    Think of it like a restaurant:
    Fast food restaurants are fast and they are cheap.
    Michelin star restaurants are slow, and they are very expensive.

    ps. I know that the difference is deeper but every other person thinks like that :)
  • 2
    @potata there is a limit though. I don't fancy walking into a restaurant, ordering and then waiting an hour for the food to arrive regardless of how good or cheap the food is...

    What they are really paying for is the knowledge and experience that it took to quickly analyse the situation and put in place a solution that works and that should be maintainable.

    If it takes a dev 3 hours to do something and your paying them 50 an hour, or you have a different dev that can do the same in 1 hour but changes 100 an hour, there your saving money with the faster dev.
  • 2
    This might work equally well as a plaque on a sysadmin's desk or on the wall of a brothel.
  • 2
    I DID NOT mean to insinuate that IT employees are sometimes treated like brothel employees.

    Wait. Yes, I did.
  • 1
    @ftyross Well, you don't have to repeat that to me :) I perfectly know the situation but thinking about the average Joe - it's not uncommon for him to think like that :)
  • 1
    @ftyross And where does quality enter into your equation? How about documentation and readability?

    I'd pay more for a developer who:
    - Documented/commented his code well
    - Made his code extensible and/or easily modifiable
    - Wrote code that was well tested and worked

    Yes, experience matters but I've run into too many "over experienced" developers who write uncommented, unformatted code which handles only the primary use cases and blows up if anything approaching an edge case comes along.

    "But, it meets the requirements" is the true mark of a dev who no longer gives a shit.
  • 1
    Not true, you are owed for the (knowledge + skill) * time spent on the task

    How long you took to learn shit is irrelevant
  • 0
    @mundo03 Yes and no. The point is that because you’ve spent time improving your skill, your skill is inherently more valuable when it reaches a point where it actively reduces the time needed to perform the task.
  • 0
    @JustThat “It meets requirements” is also the mark of a developer who is avoiding scope creep so he can be sure he’s being compensated adequately for his work. Not all of us have corporate jobs that pay us just for showing up and not deleting production.
  • 1
    @Kaji what if you are an idiot and ended up being good at something after 10000 hours when it should have taken 100 hours?

    I guess what we can agree on is that experience matter. We can say experience is part of the skill component.

    I still think the time you take to learn is yours to use up and not for your customer to pay up.
  • 1
    @mundo03 Agreed. What I was trying to say (which I think you just summed up a bit better) is that your compensation for time spent learning is being able to charge more on the basis of your increased skill—or simply find more work than before as a result of it.
  • 0
    @Kaji If your customer sets the scope and they aren't controlling the creep then any developer who holds to the original scope isn't likely to be employed by that company for long.
  • 0
    @JustThat Agreed, but in the case cited by you the customer is in theory going to continue paying the company to get the work done to whatever the expanded scope is—and in either case the company is still going to pay you whatever it's agreed to for your time. The company employing you acts as a buffer here, and by all means you should follow what the PM says to do.

    My reply was pointing out that for independent contractors it's a very different ball game. If you don't control the scope creep when dealing with a customer in that situation you will very quickly find yourself working lots of unpaid time for things that will get tossed aside and undervalued. All of which takes away from time spent finding additional (profitable) work or other obligations on your end.
  • 0
    @JustThat ideally devs should value all those things greatly but sometimes there aren't enough time and/or budget to achieve all that. Depending on the project some deadlines cannot be slipped and you have to cut somewhere.

    Admittedly this shouldn't happen but we all know it does.
  • 0
    @ftyross I agree completely. However, that line of thinking and approach to software development has led to a dramatic drop in quality. Do I need to point any further than Windows 10's updates?

    If a project to build a bridge was running behind schedule due to design changes, cosmetic or functional, would we, as a society, simply accept the risk of not doing the job right?

    Sure, this happens and will happen in the future. But the people involved usually pay a high price for their shortcuts.

    This doesn't seem to happen in software.

    When scope creep is allowed to occur uncontrolled and deadlines/budget/effort isn't adjusted accordingly problems will invariably happen. The most experienced developers will make mistakes when put under that kind of pressure.
Your Job Suck?
Get a Better Job
Add Comment