Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
potata15753yWhile 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 :)
ftyross1803y@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.
This might work equally well as a plaque on a sysadmin's desk or on the wall of a brothel.
I DID NOT mean to insinuate that IT employees are sometimes treated like brothel employees.
Wait. Yes, I did.
@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.
mundo0353353yNot true, you are owed for the (knowledge + skill) * time spent on the task
How long you took to learn shit is irrelevant
mundo0353353y@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.
@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.
@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.