|
 
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Now, of a laptop overheating whilst using Win10 and it being related to paying car reg for your Audi at the DMV...YUP!
|
|
|
|
|
Yeehaw!
|
|
|
|
|
Some questions inspired by the earlier "I hate debugging" thread:
Supposing there was a scale from 1 to 10 which ran roughly as follows:
1) Get the damned job done anyway you can. Best practices? Never heard of 'em!
2) Quick and dirty's always done it for me, I try to be as tidy as I can be but I'm not going to fuss about high faluting concepts when my customer just needs a website.
3) I'll brush it up a bit when I'm finished.
4) I try to stick to some kind of decent design pattern but I'm not going to lose any sleep if I violate it here and there.
5) As long as things are done reasonably, that's cool. Yeah, I break a few rules here and there but hey y'know, you've got to be pragmatic.
6) I spend time upfront on design because good design leads to good code but I'm not going to get too obsessed with what the rest of the world does or doesn't deem to be best practice this week.
7) Best practices are worth aspiring to. I don't always use them but I do try hard to stick to the main ones.
8) Rules aren't carved in stone but there needs to be a damned good justification for deviation.
9) OMG! That line isn't covered by a unit test - that makes it LEGACY CODE! And look at that! A singleton! It's a goddamn anti-pattern! I don't feel too well ..
10) The Law of Demeter has been broken and the crops will fail if I don't rewrite the whole damned thing from scratch.
Now, obviously this is a rather arbitrary (and slightly flippant) scale but assuming a general spectrum running from Q&D via pragmatism to extreme perfectionism:
a) Where would you place yourself on the spectrum?
b) Where do you think that you should be on the spectrum?
c) What do you think are acceptable points on the spectrum for others to occupy?
d) Does your position vary according to what you're working on (e.g. is your attitude to a web-site different to your attitude to designing a database? If you write both low and high level code, does your approach change?)
98.4% of statistics are made up on the spot.
|
|
|
|
|
a) Between 7 & 8, probably.
b) Between 7 & 8, probably.
c) Between 0 & 11, probably.
d) No, not really - my personal feeling is "if a job's worth doing, it's worth doing properly". I do not like doing the same tasks repeatedly (one of the -many - reasons I hate mowing the lawn). High and low level aren't as different as you might think, it's just a different environment in which to work - there is a smaller difference between embedded code and a Windows Forms app, than between a Windows Forms app and a website for example.
I try really, really hard not to have to revisit code, but I make it as easy for myself as a can, because I know there will be bugs, will be changes. Doing the right thing now saves me a lot of effort later when I've forgotten why I did something "clever".
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
6, trying for 8
d)yes when it comes to db design, no compromises, but SOLID is relative.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
a) 6
b) 6
c) It would vary between different projects and teams. Somewhere in the middle would be good to aim for.
d) Yes. The bigger the code and the more people that would need to maintain the code, the higher up on the scale the project should be. If the code needs to be certified the number should be higher than if the code is to be used by one or two people occasionally. Good design is always a good idea and I wouldn't go below a 4 on the scale. I've seen code where developers add complexities and convolutions just to make the so-called best practice 'work'.
|
|
|
|
|
SkysTheLimit wrote: The bigger the code and the more people that would need to maintain the code, the higher up on the scale the project should be the better the job security!
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
