2 ms·

Not quite a fair comparison because most software engineers are salaried, not hourly (at least in the United States). I’m trying hard to think about what cheat

Not quite a fair comparison because most software engineers are salaried, not hourly (at least in the United States). I’m trying hard to think about what cheating would be in the software world. Here’s a few things that I see: * Grabbing an open source package without a license check * Pushing to production without running all the integration tests (or worse, just SSHing into production) * Accepting a PR without actually reviewing the code * Writing code without unit tests Its hard for me to come up with these - most involved skirting controls, which were usually there for a reason. Data science seems much more obvious: * Lying about performance on the test set * Using highly correlated features which leads to instability * telling people the model has broader applicability than it does (e.g. a speech to text model was trained on complaint phone calls and claiming it can be just as good for in person meetings) This could be because I spend more time in the ML world, but I’m curious what other people think.

zxcmx 6y ago
In my experience the primary way knowledge workers get into trouble is over-reporting progress on a task, then half-assing it at the end or making excuses. This might be due to procrastination, personal issues, distraction, other job pressures, lack of direction / guidance on the task or many other reasons, some of them good. The problem is succumbing to the temptation to report progress when there really hasn't been any.
- umvi 6y ago
  > The problem is succumbing to the temptation to report progress when there really hasn't been any. Just today at stand up I said I was going to "wrap up" a story I had been working on for several days. In reality I have not written a single line of code, so by "wrap up" I meant "start and finish coding". Here's how I rationalized it though: It's not like I've done nothing, the past few days I've been mentally digesting the story and trying to figure out how all the pieces fit together. I've been researching different solutions online, reading through GitHub and StackOverflow. I thought about it a lot, even when not at work (i.e. in the shower or laying in bed). Now that I think I've fully worked out the solution in my mind, actually coding it is the easy part. Sometimes I hit a snag, but more often than not, I can just iteratively breeze through the implementation. - I like to solve
  - m463 6y ago
    Heck, even presenting your status here on hn might even be considered progress towards completion. In fact, reading my comment will probably help you get in the zone to write the code just before deadline!
eru 6y ago
A bit of automation can help with most of the 'cheating in the software world' you mention. For example, writing code without tests can be caught with a coverage checker. In my ideal setup, you would be allowed to bypass the coverage checker with a simple comment-annotation in your code. The point is not to be bullet-proof, but to have the automation remind you to do the Right Thing; and to make doing the Wrong Thing something you explicitly have to go out of your way to commit to. Not just something that happens because you are absent minded. (And there are lots of legitimate reasons why you might want to bypass a coverage checker or a linter. So an easy, but explicit bypass is useful.)

zxcmx 6y ago

In my experience the primary way knowledge workers get into trouble is over-reporting progress on a task, then half-assing it at the end or making excuses. This might be due to procrastination, personal issues, distraction, other job pressures, lack of direction / guidance on the task or many other reasons, some of them good. The problem is succumbing to the temptation to report progress when there really hasn't been any.

umvi 6y ago
> The problem is succumbing to the temptation to report progress when there really hasn't been any. Just today at stand up I said I was going to "wrap up" a story I had been working on for several days. In reality I have not written a single line of code, so by "wrap up" I meant "start and finish coding". Here's how I rationalized it though: It's not like I've done nothing, the past few days I've been mentally digesting the story and trying to figure out how all the pieces fit together. I've been researching different solutions online, reading through GitHub and StackOverflow. I thought about it a lot, even when not at work (i.e. in the shower or laying in bed). Now that I think I've fully worked out the solution in my mind, actually coding it is the easy part. Sometimes I hit a snag, but more often than not, I can just iteratively breeze through the implementation. - I like to solve
- m463 6y ago
  Heck, even presenting your status here on hn might even be considered progress towards completion. In fact, reading my comment will probably help you get in the zone to write the code just before deadline!

eru 6y ago

A bit of automation can help with most of the 'cheating in the software world' you mention. For example, writing code without tests can be caught with a coverage checker. In my ideal setup, you would be allowed to bypass the coverage checker with a simple comment-annotation in your code. The point is not to be bullet-proof, but to have the automation remind you to do the Right Thing; and to make doing the Wrong Thing something you explicitly have to go out of your way to commit to. Not just something that happens because you are absent minded. (And there are lots of legitimate reasons why you might want to bypass a coverage checker or a linter. So an easy, but explicit bypass is useful.)