Agree or Disagree?
-
Interesting article.. What side of the fence are you? http://jhovgaard.net/how-i-stopped-writing-awesome-code[^]
Why do we not have the option of being ambivalent?
--------------------------------- I will never again mention that I was the poster of the One Millionth Lounge Post, nor that it was complete drivel. Dalek Dave CCC Link[^] English League Tables - Live
-
Why do we not have the option of being ambivalent?
--------------------------------- I will never again mention that I was the poster of the One Millionth Lounge Post, nor that it was complete drivel. Dalek Dave CCC Link[^] English League Tables - Live
-
Qubits are better! :)
--------------------------------- I will never again mention that I was the poster of the One Millionth Lounge Post, nor that it was complete drivel. Dalek Dave CCC Link[^] English League Tables - Live
-
Interesting article.. What side of the fence are you? http://jhovgaard.net/how-i-stopped-writing-awesome-code[^]
db7uk wrote:
What side of the fence are you?
Absolutely!
VS2010/Atmel Studio 6.0 ToDo Manager Extension
Version 3.0 now available. There is no place like 127.0.0.1 -
Qubits are better! :)
--------------------------------- I will never again mention that I was the poster of the One Millionth Lounge Post, nor that it was complete drivel. Dalek Dave CCC Link[^] English League Tables - Live
:thumbsup: you are making a quantum leap there, does it go over the fence?
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS My LinkedIn Profile
-
Interesting article.. What side of the fence are you? http://jhovgaard.net/how-i-stopped-writing-awesome-code[^]
I firmly agree. I often make a point of writing productive, to the point, non-awesome code. :-D
-
Interesting article.. What side of the fence are you? http://jhovgaard.net/how-i-stopped-writing-awesome-code[^]
I agree. Productive is more important. Get the code done as fast as possible then test the crap out of it and fix it. Forget the fancy engineering, do a heavy code review, get the product up and test test test. Of course the customer will find bugs. when he does, fix them and thank him. Of course DONT do this if you are writing mission critical code like military or stuff for space. In these cases the code needs to be bullet proof.
============================== Nothing to say.
-
I agree. Productive is more important. Get the code done as fast as possible then test the crap out of it and fix it. Forget the fancy engineering, do a heavy code review, get the product up and test test test. Of course the customer will find bugs. when he does, fix them and thank him. Of course DONT do this if you are writing mission critical code like military or stuff for space. In these cases the code needs to be bullet proof.
============================== Nothing to say.
Erudite_Eric wrote:
Productive is more important. Get the code done as fast as possible then test the crap out of it and fix it. Forget the fancy engineering, do a heavy code review, get the product up and test test test.
I kinda like this one. Might put it on my signature, with your permission of course.
Erudite_Eric wrote:
In these cases the code needs to be bullet proof.
In these cases, JSOP is the man.
Signature construction in progress. Sorry for the inconvenience.
-
Interesting article.. What side of the fence are you? http://jhovgaard.net/how-i-stopped-writing-awesome-code[^]
Awesome code IS code that solves the problem. It's as simple as that - if your code doesn't solve the problem then your code is not amazing. Solving the problem isn't just satisfying the customers request, it's also leaving the code in a state that it can be fixed, enhanced and understood at a later stage. That's awesome code.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier
-
Interesting article.. What side of the fence are you? http://jhovgaard.net/how-i-stopped-writing-awesome-code[^]
I pretty much agree with the content (though like others, I don't think that 'awesome' means 'using lots of frameworks' in the first place). I don't agree with him on unit tests, though; unit tests are essential for providing back-end flexibility. Some end user tests (integration tests or system tests, scripted if possible) are a good idea as well, but unless it's a super-trivial business logic tier, I'd still unit test it. I absolutely agree with him regarding dependency injection frameworks. They're a pain and the flexibility they give you is not needed for 99% of the project (and where it is, you'd naturally write an interface and some kind of plugin architecture anyway) – under the YAGNI agile principle (you ain't gonna need it) you shouldn't be complicating your life for something you aren't likely to use. Interfaces can be good for modularisation and reduction of dependencies (for example making mocking for tests easier), but you don't need to use them everywhere and you don't need to use dependency injection to create instances of the real objects. I previously worked on a project where everything was wired up with IoC (C#, Unity) and tracking down bugs and making changes to constructors was hugely difficult. ORMs are great if you play the game by their rules, in particular if you can use them from the beginning and let them construct the initial empty database. As soon as you are trying to interface to an existing database, with joins and columns that aren't necessarily directly mapped to what you want in the in-memory representation, they become difficult. I wrote a simple data mapping layer because I didn't want all the complexity and persistence logic of a traditional ORM, to map to an existing database, and I really enjoyed the experience of working with that, because it let me specify when queries would happen and what would be in them. I don't agree about repetition vs simplicity, DRY (don't repeat yourself) is the rule I put at no. 1 in my coding, and the extra complexity involved in calling out to another method is minimal.
-
I agree. Productive is more important. Get the code done as fast as possible then test the crap out of it and fix it. Forget the fancy engineering, do a heavy code review, get the product up and test test test. Of course the customer will find bugs. when he does, fix them and thank him. Of course DONT do this if you are writing mission critical code like military or stuff for space. In these cases the code needs to be bullet proof.
============================== Nothing to say.
