|
usually working on back room [db] apps, about 8, with justifications:
1. solution must fit business requirements - never visa versa
2. even more must [and as efficiently as possible] fit the physical work flow.
small to medium sized businesses have often developed their own in-house work efficiencies that for capture and reporting don't always fit well with [mostly database] best practices.
(So the question is: the "best practices" are for who? - for mine many are really only "best" for keeping newbies in line until they learn how to fly.)
Sin tack
the any key okay
|
|
|
|
|
I think your list is very interesting.
I think the main two categories for answering this are:
1. sole programmer at company who will never really be replaced.
2. programmer is a part of a team
For 1 - I don't care what the code of the sole programmer looks like. It's his own foot he'll shoot off later anyways. Just make the doggone thing work! In every way, performance, security, everything. I don't want to see your code. I don't even want to smell your code, no matter how stinky it is. But you better be able to fix it fast when it breaks in production or when there is a new Windows API and it breaks or whatever. Fix it and no whining.
For 2 - If i'm going to look at your code and you're going to expect me to do something with it, make it clean. Use patterns, use great variable names, use true OOP and SOLID principles.
And, if I come to you and say, "Hey I need to convert HTML to PDF and you've already done that in the Chupacabra software, right? Can I just get that method from you?" then you better be able to say, "sure, it's in a library just add it in and call ConvertHTMLToPDF(htmlFile) and you are done.*"
And, right, I don't care about rules** even if they're named best practices. However, I do actually care about best practices and code conventions that make my life better. Plus, if you are following what I said in 1 or 2 above then all is good and easy anyways, because it is right. 
*That's a true story where I went to someone who had that, but the code was inside his WinForm class. Couldn't be used. Ugh!
** ~Edison Hell there are no rules here. We're trying to do something.
|
|
|
|
|
Overall:
a) 7
b) 8
c) 7
d) Usually I couldn't care less about some interface implementation as long as the overall design is good.
So for the architecture I'm probably a 7 or 8, while for the implementation I'm leaning more towards 3 or 4 or even 2. The implementation should be easy to fix anyway, while the architecture isn't!
Too bad I often find some disposable code all polished up and unit tested while the architecture looks like spaghetti 
|
|
|
|
|
Anywhere between 0-10. Let me explain:
1-3: Experimentation code, usually when I'm learning something new or putting together a proof of concept. Once I have a handle on the tech, I move the code into the next category.
4-6: This where the balance between "how much effort do I put into this?" and "oh yeah, the client is paying me hourly for this code?" starts to take effect. There's also the temporal effect, being that my code stays in the 4-6 space for various time intervals, from very short (minutes) to very long (months), depending on how entangled it starts to get with other code. Some stuff is just a one-off utility, other stuff gets merged in with the rest of the code base and needs cleaning up at that point.
The 4-6 space is also where I live when I've attained some knowledge of the technologies and requirements, but certainly not mastery. (Mastery of requirements usually occurs over time as the client/customer provides more detailed feedback.)
7-8: Ultimately, my code tends to end up in this space, but my concept of best practices are rather different than "industry standards," or so I imagine, since I really have no idea what "best practices" means since it seems to be such a moving target. So I've evolved my own. At this point, in order to get into the 7-8 space, I must also have achieved mastery over the tech, the requirements, etc. This is where long term projects live, and they live because they are maintainable and easily enhanced.
9 - line by conditional line of unit testing, anti-patterns, and whatever else fits in the religious zealotry of the best practices category is a red flag to step back into the 7-8 space.
10 - Yeah, there's often a jump from the 4-6 space to the 10 space to get to the 7-8 space. The pain of learning how to things right. 
As for c), I'd say at least the 4-6 space, and if you think you're code lives in the 7-8 space, you'll have to answer to me, mwahaha.
Marc
Latest Article - Create a Dockerized Python Fiddle Web App
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
a) wandering between #6 and #8
b) would depend on the context, and the current project
c) would depend on the context, and the current project
d) probably
I do think that the larger the team size, and the more complex the project, the more formal development methods, and stronger management, are required
from the sidelines, Bill
«When I consider my brief span of life, swallowed up in an eternity before and after, the little space I fill, and even can see, engulfed in the infinite immensity of spaces of which I am ignorant, and which know me not, I am frightened, and am astonished at being here rather than there; for there is no reason why here rather than there, now rather than then.» Blaise Pascal
|
|
|
|
|
a. Sort of an off blue
b. Red
c. That's their problem
d. Okay I do full stack so it's like a car where you need all 4 wheels so why make any attitude difference.
In our shop the best practice documents are only available to managers, and they only communicate in short cryptic emails.
Leadership equals wrecked ship.
If you think you are leading my look behind you. You are alone.
If you think I am leading you, You are lost.
|
|
|
|
|
Item 6. I've been doing this for 40 years and if a client needs something developed "My own counsel will I keep" on how it is done. There are definitely good practices out there but the majority of them are based on someone's opinion. If the idea has merit and works better than the way I'm doing it without becoming overly complex, I'll adopt it. Otherwise I'll use what works best for the client and keeps life simpler for me.
If you think hiring a professional is expensive, wait until you hire an amateur! - Red Adair
|
|
|
|
|
a. Between 7-8
b. Between 7-8
c. Between 2-8 (less than 2 or greater than 8 make them hard people to work with)
d. It does some. If I am writing an example to help someone, It will be sparse on rule following. If it is an answer on StackOverflow or CodeProject, it may push toward following the rules more in order to be a more correct answer. If it is code that I have any possibility of fixing bugs in or doing maintenance to, I will be liberal in documenting and making the code as readable and maintainable as possible. Since I am 62, forgetfulness is a driving force for this. High level and low level are no different at all.
|
|
|
|
|
If noone sees my code except me, is it still sh*tty code?
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
a) 6-7. If you don't ship code in a timely manner, there's no paycheck. If you can't add new features in a timely manner, there's no paycheck. If you get the design right, even if it isn't a blessed Best Practice, then paychecks happen.
b) 6-7. I've worked all around that spectrum, and found the happy medium to be 6-7. Anything over 8 is detrimental to shipping a product though.
c) Wherever they need to be for their project, organization and desired maintainability.
d) Not really. I try to put some up front thought into every non-throwaway design regardless of whether its high or low level because I'll end up with more maintainable code. However, sometimes other factors trump that.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
a) It depends on my role. For mobile software I'm usually hovering around 7. In the corporation where I work (doing enterprise development) I try to stick around 8.
b) Honestly I think 7 and 8 are the most reasonable. At 9 or 10, while something to be aspired to, I don't really think is reasonable.
c) Anywhere from about 6 on up should probably be the way to go.
d) Definitely. If I'm just developing a website I would probably do the bare minimum to get it up and running and then fix it later. But, when writing mission critical software, then I try to go the extra mile because I don't want a bug coming back to haunt me for any reason.
|
|
|
|
|
I'm going to a fancy dress party – I selected a Darwin costume, naturally.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
It'll be a long party, probably feel more like an endurance event
Sin tack
the any key okay
|
|
|
|
|
Are you going to bring your Beagle?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
absolutely, need somewhere to stow the samples
Sin tack
the any key okay
|
|
|
|
|
Just wear the one that fits best.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
The missus can go as Lady Godiva then.
|
|
|
|
|
I'd just go in some genes.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
DNA have yeer kilt laddie?
|
|
|
|
|
And, yet, the jokes fail to evolve... 
|
|
|
|
|
Well done!
"Google Project Zero's Windows bug-hunter and fuzz-boffin Tavis Ormandy has given the world an insight into how he works so fast: he works on Linux, and with the release of a personal project on GitHub, others can too.
Ormandy's project is to port Windows DLLs to Linux for his vuln tests (“So that's how he works so fast!” Penguinistas around the world are saying).
Typically self-effacing, Ormandy made this simple announcement on Twitter......
Ormandy's reason for the project is to let loose fuzzing against Windows-based software, using Linux platforms.
“The intention is to allow scalable and efficient fuzzing of self-contained Windows libraries on Linux. Good candidates might be video codecs, decompression libraries, virus scanners, image decoders, and so on,” he writes.
Efficiency is the key, with Ormandy writing that on Windows, it's all too slow."
What's got a vast attack surface and runs on Linux? Windows Defender, of course • The Register[^]
|
|
|
|
|
If this ever becomes more than a research project, you can bet Microsoft will have something to say about it. 
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Richard Andrew x64 wrote: If this ever becomes more than a research project, you can bet Microsoft will have something to say about it.
You mean like what they've done over the last 20+ years with WINE?
/sarc
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
|
Samsung S8 'eye security' fooled by photo - BBC News[^]
I always remember a long time ago Mythbusters set out to test fingerprint authentication as found on anything from laptops to bank vaults. To prep for the feature they had a range of devices that offered fingerprint authentication all the way up to very expensive vaults and they also had a range of possible solutions to try. No doubt they were planning on starting with the more basic bits of kit and the most basic tools to circumvent and they'd get more and more sophisticated with their tools until the device was cracked. They would then move up to the next more secure device and repeat the process.
The simplest way they had to beat the system was a photocopy\printout of a fingerprint. The most complex involved a finger modelled in ballistic gel which matches the conductivity of human skin, and they had a mechanism to ensure the gel was also heated to body temperature. They basically tried to make the most realistic finger they could.
The whole bit was a damp squib though as the result was that the most basic of methods (a printout of a fingerprint) cracked the most advanced of the devices (the professional safe).
It's like the security industry is constantly looking for the next "big thing" and trying all these gimmicks and it's as if the gimmick is the most important thing....even more important than if the method actually works, and the end result is that things are getting less secure, not more.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
