4 ms·

Depends how you define good. Some define good as getting the job done in a quick and efficient manner and making the client (or company) happy with the result,

Depends how you define good. Some define good as getting the job done in a quick and efficient manner and making the client (or company) happy with the result, however code quality may suffer in this instance and it could be hard to maintain. Others define good as writing the highest quality code with high test coverage, deployment procedures, writing detailed JIRA tickets, great documentation, training other developers in the team on the system, making the front end pixel perfect, recommending and implementing better features and improvements into the project, etc etc. As you can tell these people may suffer from inability to meet deadlines and getting things out the door. Ideally you walk the line between them both. Personally, I'm in the former camp, but I'm more a business owner than a coder, so deliverables are more important than the best programming methodologies. It depends on what the priority of the business/department/team is.

nickthemagicman 9y ago
Deliverables is misleading. Would you rather a deliverable full of bugs that can't scale but is delivered 'on time'?
- fragmede 9y ago
  Why not just build code efficiency requirements and correctness into the spec then? Hah, I'm just kidding, I've worked long enough to know no one ever has a spec. (I've heard things about various NASA projects but have never worked there.) What is this deliverable for? TechCrunch Demo? The only metric a demoable build, and even then people understand it'll have bugs. There are still places where there's a drop dead date for code (firmware; physical media) but continuous deployment on the web turns that on its head - the software is constantly evolving; there's no single deliverable that's set in stone and can never ever be changed. Developer hours is a very limited resource, better to launch the product with slow code and parallelize thanks to the cloud and optimize once hotspots are identified. "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -Donald Knuth.
- mercer 9y ago
  Sometimes, yes. I've worked for a startup where the plans changed enough to have significant effect on the code. Rewriting a lot of it ended up being necessary and actually well-justified. As a more careful programmer, I wasted everyone's time making 'the right choices' when in this particular context, in hindsight, I could've known that rewriting the whole thing was a likely scenario. If I'd get the same job now, years later and (I hope) wiser, I'd have built a much quicker, dirtier, buggier version (essentially a prototype/alpha) instead.
- deleted 9y ago
  [deleted]

nickthemagicman 9y ago

Deliverables is misleading. Would you rather a deliverable full of bugs that can't scale but is delivered 'on time'?

fragmede 9y ago
Why not just build code efficiency requirements and correctness into the spec then? Hah, I'm just kidding, I've worked long enough to know no one ever has a spec. (I've heard things about various NASA projects but have never worked there.) What is this deliverable for? TechCrunch Demo? The only metric a demoable build, and even then people understand it'll have bugs. There are still places where there's a drop dead date for code (firmware; physical media) but continuous deployment on the web turns that on its head - the software is constantly evolving; there's no single deliverable that's set in stone and can never ever be changed. Developer hours is a very limited resource, better to launch the product with slow code and parallelize thanks to the cloud and optimize once hotspots are identified. "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -Donald Knuth.
mercer 9y ago
Sometimes, yes. I've worked for a startup where the plans changed enough to have significant effect on the code. Rewriting a lot of it ended up being necessary and actually well-justified. As a more careful programmer, I wasted everyone's time making 'the right choices' when in this particular context, in hindsight, I could've known that rewriting the whole thing was a likely scenario. If I'd get the same job now, years later and (I hope) wiser, I'd have built a much quicker, dirtier, buggier version (essentially a prototype/alpha) instead.
deleted 9y ago
[deleted]