Hacker Newsnew | comments | show | ask | jobs | submit | bermanoid's comments login

Since I moved into a lead role (where I still do day to day coding but don't do as much as my reports), a good rule of thumb for me has been that if I can't track down the offending line of code within half an hour based on a stack trace coming in from a significant portion of end users, someone has overarchitected something.

Figuring out when something is too simple is trickier, but it tends to be pretty obvious because a ton of bugs come in that are easy to locate.

Over the past few years, I've decided that as a general rule I prefer engineers that under-architect to those that take it too far, because the damage is far easier to mitigate...

-----


Can you explain the actual difficulties?

In particular, do you question whether the quality of the image would be high enough, or whether the ML techniques can automate what a lab tech does while looking through a lens, or is the problem that seeing blood is not enough to diagnose much of anything with any certainty?

"Reliable rate" is relative, and something that I've found lacking in modern medical care in the US even when it's a dude in a lab coat looking at samples through a state of the art microscope...

-----


44€/hr is low, that's pretty much entry level for quality work. People routinely charge multiples of that amount; if I was to go back to contracting now, I'd be charging at least twice that much, probably more.

Also, you should not allow a client to try to renegotiate price after the work has been delivered. Especially on a fixed bid project where they're satisfied with the results (BTW, you probably shouldn't be doing fixed bid until you're a lot more experienced, if even then - hourly is much safer until you know how to deal with problem clients).

If you are going to do fixed bid, you shouldn't need to count your hours, unless you're personally curious. I'd just hope that you have a seriously tight set of acceptance criteria put down in writing that legally binds them to a definition of "done". Nothing in that document should involve your hours: the only reason to take on fixed bid work is that you're betting you can do it in fewer hours than they're implicitly estimating it will take. If you win that bet, then that's great, the client should still be happy with the agreed upon amount but there's no need to show them how the sausage is made.

-----


Thank you for your reply! I found it well thought and I'll surely memorize some bullet points for my later career.

I've been very humble with my pricing so far because people don't really take me seriously if I try to pull that kind of wages. You see, I have neither a degree or the age which would do the trick. Past work is kind of there, but instead of URLs the clients I've met in person just want to know whether their software can be done. Peers my age are working in labor jobs for the normal 9to5 and some even brag how they can pull out 17 hours of work in 24 hours. I've noticed that people treat software development with the very same idea, where the young have the endurance to pull out sick work hours and where more hours equals more work done. People seem to be afraid of hiring someone who says their hourly wage is starting from 40€, especially when the person can't, thanks to their lack of experience, say how many hours they'll eventually need. Therefore, for the sake of getting any clients in my first steps of lone entrepreneur, I've decided to stick with the lump sum.

It really is a pity that I can't get around keeping the work hours as my own business, but so far I've found it easier than introducing them completely new way of working, where part of the time is spent on thinking instead of doing work. Until the latest incident, I had never even crossed the idea that the client may think they are getting screwed, thinking that the work they asked was really just that easy to do (because I was left with so little hours).

But about the price negotiation, yes, I agree with you and I'll not let them do that. Our negotiations had no agreement on the hours I should spend, so they have no reason to drive the price down because of that.

I'm going to be honest with you and tell you that I haven't made a single black-on-white agreement on what defines "done". Instead, the idea has been that I'll remain as the lone owner of the software, with the exclusive rights to re-sell it. I'm currently looking for the chance of turning the software into a SaaS, in which the original client has agreed on helping me by referring businesses from the same field to use it. So basically, I'm charging the original client one year worth of the subscription I've been planning on selling it for. By so, I'm basically securing at least one customer for the service for one year. At the same time, I'll basically launch a service which has proven to have at least some kind of demand. Plus I get free marketing from the original client on the same run.

You see, if they would be able to refer even two customers, I'd be glad, as that's the turning point where it's financially sane for me to get a LLC for my programming work (that's a huge thing for me in a country where you lose most of welfare state's benefits by starting one). Everything above that is really just a bonus. But should I get 20 recurring sales, I'd already make enough money that I could live (in theory) the rest of my life with the money I make from the product per month. You could say it's a risky shot, but as long as I can do the thing I like and get paid for it, I'll keep choosing the risk.

-----


I was contracting about two years ago and charged €60/h. I'd charge closer to €100/h or more if I did it now.

you should not allow a client to try to renegotiate price after the work has been delivered

Completely agree. The "Fuck You: Pay Me" video has some good tips on contracts and making sure additional work is billed separately etc. The price should be set in stone before any work begins.

-----


You're right that people give professional favor based on personal affinity, what I'm not sure you're right about is that it's so wrong to do so. If I don't like you, then it's likely that your direct reports will feel the same way, as will potential clients or partners, which is a risk to the business, so I'm not likely to choose you for a position that puts you in a position to interact with many people. Most high senior positions require a ton of soft skills, so you're probably going to hit a ceiling unless you prove that you have them. Making your manager and peers like and trust you is step 1; the best people go far beyond that very quickly.

Nobody ever promised that career progression would be based on coding chops, especially when each jump up the ladder means less time coding and more time people-hacking.

-----


Likeability is neither transitive nor uniform across a population. It's quite common for someone to be well-liked by some people and disliked by others for quite arbitrary reasons; it's also common for two people that you both like to dislike each other. Actually, highly successful people seem more likely to show this polarization, where they are liked by some and hated by others, simply because they are less shy about putting their personal opinions out there and people will have a wide variety of reactions to those opinions.

-----


In math, there are many "proofs" that 1 = 2. Going through them and picking them apart is a useful exercise, and can expose misunderstandings and mistakes that are important to be aware of. But at the end of the day, nobody really seriously considers that 1 actually equals 2, it's too at odds with everything else we know.

This article is saying that it's possible the FT piece found a valid nitpick, but that the conclusion they're fighting against (rising wealth inequality) is backed up far too strongly by other independent sources for a nitpick to damage it at all.

-----


Not at all - the day you went wrong was the day you wrote code that worked and assumed that the people paying you would let you rewrite it later.

That never happens, unless you force the issue by making the first version fundamentally unsalvageable through choice of language or something like that.

If you don't know for sure that you can't (for a very real reason, like the fact that AS3 won't run on iOS) ship a line of code, it's on you to assume that everything you write is going to get to production. That's the reality, even if it's uncomfortable.

...I say as the lead on a game that just got sent in for review today, 8 months early, with 95% of the "prototype" code that we started a few months ago intact. Luckily we never believed that it was actually prototype code, because wasting a month and a half to recreate something that already works is a hard sell to anyone that hasn't struggled with the codebase already.

Pad estimates, and plan for the worst, is all I can suggest. But also realize that sometimes short timelines are a blessing: the people that would be filling up the feature request list stop doing so once you tell them that you're already overcommitted by 80%. That helps the product, usually.

-----


We were asked to produce a prototype in a two month time frame and we did. It was the subsequent unrealistic time frame after we demonstrated the prototype that did the damage.

-----


"200 years" and "evolve" should never, ever, appear in the same sentence.

-----


You're not thinking very hard. How long does it generally take to get a new breed of dog? How many generations of E. Coli will occur over 200 years? Assuming a human generation length of 25 years, why would there be no evolutionary change over 8 generations?

-----


Selection for existing attributes is plausible on 200-yr timescale. Pro-adaptive mutation is not.

-----


To within measurement error, all attributes are pre-existing attributes. It's called "natural variation" and is the universally-accepted explanation for why we have sexual reproduction instead of budding. Right now, some people are more radiation-resistant than others.

-----


Evolution did just fine, and it's far more scattershot than our current efforts at AI.

You're also crucially missing the possibility that someone comes up with an intelligent algorithm that doesn't mirror the human brain in much detail, but still manages to outperform it. Think of flight: inventing flapping machines didn't turn out to be very useful, but we figured out a workaround that was far more efficient. The most interesting (terrifying?) AI research is along these lines.

-----


The fact that a few gay people support something doesn't make it any less offensive, homophobic, or idiotic.

-----


These "workers" that are being "exploited" are just copying and pasting code, in this situation. In this case, the code doesn't even work properly, since it's calling someone else's analytics callback. No work has gone into this, just willingness to steal code.

That's called cheating the customer...fuck these guys. Even if they need the money.

-----


I admire your certainty. Maybe it is as simple as that and I'm overthinking it.

I can't quite express the difficulty I'm having in a comment so I'll try to write it up some time.

I can't argue it yet, but my intuitive feeling is that it's socially irresponsible to create this economy for them and then pull the plug like this. The bigger picture, I think, is that OP got his code stolen which sucks, but the contractor (or one like him) may have to sell a kidney or go back to working 18 hour shifts in the factory with toxic fumes now. That doesn't seem proportionate.

-----


The market your talking about (software-mediated freelance development) only works if the participants trust each other. If Odesk allowed the Indian programmer to steal IP, that creates a precedent, our at least a perception, that theft is OK. This perception discourages western customers from using the system.

This shrinks the market, reducing demand for programmers in India. Now MANY Indian programmers can't find work, even ones who were honest and efficient.

I think this effect is very important to keep in mind if you're concerned about the morality of the situation. The thief is hurting his fellow Indian programmers just as much as his western customer.

-----


Getting your car stolen sucks, but if you report it the thief may have to go to jail, and who's going to feed his family then?

Protecting wrong-doers because "we" have supposedly created a system that forces their hands makes no sense.

-----


I watched a dilemma like this unfold first hand when my landlord had his bike stolen by an illegal immigrant. He didn't want a drunk stealing the bike off of his porch, but he didn't want him to get in so much trouble that he got deported either.

-----


Then maybe the thief shouldn't have stolen it.

-----


I believe the point is some of us have aspirations for a society that minimizes the number of people in terrible situations. The idea being that some of us feel many of these terrible choices are as much the result of circumstance as otherwise.

-----


Particularly for someone like me who doesn't believe in immigration control at all, deportation (or even subjecting someone to the horrible abuses of ICE without actual deportation occurring) constitutes a cruel and unusual punishment for a crime that should be punished by a fine or a few days in jail.

If I knew a drunken bicycle thief-citizen would be imprisoned for years, I wouldn't report them, either.

-----

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: