21–30 of 34 posts
Honest advice... the real engineering world is never about perfection. Most of the time you have a lack of business information, requirements missing, no test cases, etc. The bigger the company, the larger chances to see code that is far from perfection are. Business process and large amount of teams make it harder to acquire all information needed to engineer things. Also, most of the time it is about satisfying a c…
google, banking, surgical robots, etc. look at companies that kill if they fuck up. dont count on random crup web app shop to give a crap about clean code.
> crud web app shop CRUD != crud I don't know if you are making this error, but I it all the time on /r/cscareersquestions and it is a foolish conflation. crud: crappily-built product CRUD: a set of UI operations on records in your data model. You can totally have a well-built CRUD app maintained by a team that cares about code quality.
The worst CRUD applications, is where they've been extended where they are no longer CRUD but the architecture still assumes CRUD.
google, banking, surgical robots, etc. look at companies that kill if they fuck up. dont count on random crup web app shop to give a crap about clean code.
> crud web app shop CRUD != crud I don't know if you are making this error, but I it all the time on /r/cscareersquestions and it is a foolish conflation. crud: crappily-built product CRUD: a set of UI operations on records in your data model. You can totally have a well-built CRUD app maintained by a team that cares about code quality.
maybe it was intentionally conflated to call CRUD usually crappily-built
maybe i dont subscribe to your nomenclature
maybe you can have well-built crud apps (omg I did it again and this time its an oxymoron), but if you pick out a crud app at random, I'll give you 10:1 odds that its code quality is absolute garbage
Good luck.
Earlier quoted context omitted.
That's also exactly what I don't want. It's more paperwork than code in such places all full of rigorous validation.
How do you expect a company to keep to their code to the highest standard without continuously and rigorously validating that the code is actually up to standard?
You do have to ask whether the code does what it's supposed to do. What is your objective evidence that it does so? You need that.
But you don't need aerospace standards unless you're critical infrastructure. If you're writing a web app? Not so much. You'd still like to be able to not throw up when you look at the code, though.
If you insist on the standards of a perfectionist, though, you may be forever disappointed.
google, banking, surgical robots, etc. look at companies that kill if they fuck up. dont count on random crup web app shop to give a crap about clean code.
> crud web app shop CRUD != crud I don't know if you are making this error, but I it all the time on /r/cscareersquestions and it is a foolish conflation. crud: crappily-built product CRUD: a set of UI operations on records in your data model. You can totally have a well-built CRUD app maintained by a team that cares about code quality.
Killing someone by blasting them with Xrays is a very costly error, better to spend more (time is money) on quality. An html form failing in some obscure way for 1 out of every 1000 people resulting in a small $ loss isn't too vital out of the gate and acceptable if it can easily be fixed after product launch without a bunch of hassle. An app crashing in an enterprise that's locked in to some lame contract is even less vital. Like they paid some contract firm to one off some software with no real discussion of support.
I also focus as an architect on splitting up the projects into small modules that can be developed, unit tested, statically analysed and integration tested. Those who work on these are being trained up in each stage of the process and are getting better and better at it - they can't move onto the next module if the existing one isn't complete, so it spreads out the work they don't like (or have never devoted the time to learn the skills for) so it's not left to the end (and then not done). We're building lots of software components to a very high standard with very little technical debt being stored or rework being required. My employer's been realising the amount that quality issues are causing a lot of trouble (delays, costs, etc), so they're highly supportive of this kind of work and my high standards are appreciated. I work in embedded software, so software updates in the field are painful, sometimes embarrassing, and potentially expensive.