←back to thread

268 points behnamoh | 1 comments | | HN request time: 1.992s | source
Show context
kornakar ◴[] No.28668066[source]
This reminds me of my game development job I had years back.

I was new to the field (but not new to software development) and there was this small software team doing programming tasks for the game. The lead developer was concerned on my performance after a few months I was there.

I remember him drawing an image excatcly like the second picture in this article (an arrow going from A to B). He said that my performance was very poor, and then he drew another picture that was like the circle in the article.

The way I worked was searching for a solution, going wrong direction a few times, asking designers for more information and then eventually landing on a solution (that worked, and users like it).

But I was told this is wrong way of doing software. I was not supposed to ask advice from the users (because the team "knew better").

He also told me that a good software developer takes a task, solves it (goes from A to B), and then takes another task.

After a few weeks I was fired from that job.

To this day I'm still baffled by this. The company was really succesfull and everyone knew how to make software. It seemed like a very harsh environment. Is it like this in the top software companies everywhere? Like the super-pro-developers really just take a task and solve it without issues?

replies(12): >>28668113 #>>28668137 #>>28668138 #>>28668139 #>>28668191 #>>28668254 #>>28668778 #>>28669170 #>>28669289 #>>28669499 #>>28669533 #>>28669735 #
resonious ◴[] No.28668138[source]
In my own experience (and opinion), your style of development often results in better quality code, less bugs, and cleaner UX. The tradeoff, as you experienced, is time.

I can also tell you that maximum code quality is not always the priority. This is especially true in games, where you ship and then move onto the next project. Even online games nowadays often shut down after not long, and so they don't need quite as much maintenance as a successful SAAS.

Again in my experience, the super-pro devs I know are particularly good at knowing when to be fast and reckless, and when to be slow and calculating.

replies(3): >>28668743 #>>28669135 #>>28670186 #
taneq ◴[] No.28670186[source]
> The tradeoff, as you experienced, is time.

This is true, but it's not the tradeoff most people think. It's not "this way is better but takes more time", it's "spend time now vs. spend time later."

In my experience, you will always spend the time. Spending it earlier can be difficult when you're on a tight schedule which is driving the process, but you'll always spend at least as much time later.

replies(2): >>28670532 #>>28671877 #
1. aidenn0 ◴[] No.28671877[source]
You only spend the time later if you're still working on that project later. It could have failed, done it's job, or you could have moved on to the next project leaving some other poor schmuck to spend the time later.