|
Thoughts and prayers for our programmer friends from the Sunshine State (Florida), as Hurricane Milton will be making landfall this evening.
![Rose | [Rose]](https://codeproject.freetls.fastly.net/script/Forums/Images/rose.gif)
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
We're still recovering from Helene!
Luckily this one is going south of us and will have minimal impact.
A home without books is a body without soul. Marcus Tullius Cicero
PartsBin an Electronics Part Organizer - Release Version 1.4.0 (Many new features) JaxCoder.com
Latest Article: EventAggregator
|
|
|
|
|
Perspective is everything. I know someone in south Tampa and she's freaking out right now. Can't say I blame her.
Did you get through Helene ok? And of course, did all your computers survive?
Jeremy Falcon
|
|
|
|
|
Not the best time to go see Mickey Mouse.
Stay dry everyone in the area.
Put your backups in dry bags.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
Just saw this video this morning (safe for work), and it's worth noting that in Windows 11 24H2 Explorer apparently links to Recall.
Of course, their PR blah, blah says you can disable it (for now), but it's the whole frog slowly boiling thing going on. If it records your entire screen, you'd think there would be no reason for Explorer to link to it directly... unless it's also doing other things we don't know about.
Will I install 24H2 personally? Probably. Will I make sure I keep up with Linux if this gets worse? Damn right I will.
Food for thought.
Jeremy Falcon
modified 2hrs 20mins ago.
|
|
|
|
|
I've been in software development a long, long time. And I've always believed that the Analyst Programmer role was the best option, when it comes to getting things done. I should qualify that:
- an Analyst Programmer needs to have a good understanding of both the business and the technology/systems
- by "best", I mean most efficient.
This was borne out a couple of jobs back, when the software development team I was working in, consisted of experienced developers - and Analysts who had less understanding of the business, (than the developers), and no understanding of the technology/systems. Invariably, on receipt of a spec, developers would need to: identify actual requirements by talking to users; correct half-baked ideas that weren't in line with the technolgy; and devise their own testing. Analysts were actually making the whole job more difficult. Most - if not all - of the senior developers would have provided a quicker/better solution if they had done the analysis and spec work themselves. Yeah. Analyst Programmers.
Don't get me wrong. There are developers who shouldn't be let near a spec... or a user... and, in some cases, a keyboard. But they are the exception.
But there is one "blind spot" that a developer needs to overcome before taking on any sort of analysis role. Fast forward to today. I'm currently doing a few small jobs for a big company that has a small development team... and a "Solutions Architect". The Solutions Architect has been with the company for many years; started there as a programmer; has an in-depth understanding of both the business and the technology; and produces all the specs. But...
His mind-set is 100% that of a developer He has that "blind spot". And it's right there in his job title. What I want from a spec is a clear explanation of the problem - ideally with examples, that can provide the basis for testing. Want I don't want from a spec is just a solution. It's an easy trap to fall into. Developers tend to be fixers/solvers of problems - i.e. solution providers. If you can't explain the problem - the "why we need to do this" - you shouldn't be producing specs.
Remember... this just MHO. 
modified 4hrs 20mins ago.
|
|
|
|
|
I know a guy who's completely into the technology, but has no eye for businesses.
He'd send out emails to customers saying stuff like "When you click the button we do an AJAX call and in the POST we store the entity in the database through a foreign key relation."
Well, maybe not that bad, but you get the idea.
Luckily, I checked his emails before he'd send them and it simply didn't occur to him to simply say "when you click the button we store the product."
That was way to simplistic according to him.
I once had a customer who didn't want to speak to a coworker anymore exactly because that coworker talked like that and the customer didn't understand him and wasted his time.
Because I've worked with many developers who are like that I'm for the duo.
An analyst, preferably one who also has technical knowledge, and a developer, going out to talk to the customer together.
They can both see how the customer works and what they do and after that the analyst can work it out, but the developers isn't blank either.
It's also good for the users and developers to get to know each other because it becomes easier for either of them to send and email or just pick up the phone.
Of course there are also many companies who shudder in fear of the idea that a developer and a user are in direct contact with each other.
|
|
|
|
|
The spec I just received sounds like it came from your guy. In a nutshell, it was:
- Remove hard coded Customer Type from routines A and B.
- Hard code Customer Type in routine C.
There was literally, no explanation as to why/what the problem was - and not one example. The coding took about 15 minutes. I then asked him for pointers on how to test - and this is what I got back: "The Customer Type is incorrectly set to 'X' which results in the wrong value in the transaction". 
Sander Rossel wrote: Of course there are also many companies who shudder in fear of the idea that a developer and a user are in direct contact with each other.
and sometimes they're right! 
|
|
|
|
|
Years ago I worked on a sub-part of a business application, that was written in Assembler. When the spec came over from the Analyst(s), it even told us which registers to use at each step.
|
|
|
|
|
I worked with someone like that Richard, his specs were so good/detailed/accurate he might aas well of coded it (and he could of).
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
Yeah, been there done that 
Sometimes I just ask "what are you trying to achieve?"
And if they'll say "that customer type is not hard coded."
I'll follow up with "and how does that affect the outcome?" or something like that.
|
|
|
|
|
I've worked with people like that; they get completely engrossed in the detail to the point that they can't see (or explain) the bigger picture.
|
|
|
|
|
Oh yeah, but this works two ways!
As a developer I've sometimes been kept from the bigger picture.
For some reason, people sometimes see us as idiots who wouldn't get it anyway.
Probably because we're to up in our technology.
Now that I'm a manager myself I always try to get a tour of the factory (if applicable) for me and the programmer(s).
If it's not a factory I at least try to explain the overall process, like "we get document A in an email and after that they open our software and do X and Y so at the end a price is emailed back to the customer".
|
|
|
|
|
A small part of my job is to provide support for customers. I avoid get into implementation details, but I don't shy away from trying to explain, at a high level, why things work do they (or don't) either. I never try to sound condescending however.
I think most customers appreciate the fact that I don't treat them like idiots. At the same time, I don't "go deep" as I would with my developer coworkers.
It's a fine line.
|
|
|
|
|
Same!
I even have a customer who asks me about it and says he appreciates that I take the time to explain it to him in simple terms 
|
|
|
|
|
There are a lot of confusion between job titles and what they should actually do.
The Analyst Programmer will/should be responsible of the technical aspect on how to implement what the business analyst wants (after talking to the clients... )
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
xkcd: University Commas[^]
Two questions:- Any UNICODE experts here?
- If there are, are there different code points for each type of comma?
This is what occurs to you when you wake up with the start of a migraine and you are working "chemically enhanced".
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: are there different code points for each type of comma?
Gnome characters says no. 
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Comma, comma, comma, comma, comma chameleon
You come and go, you come and go
|
|
|
|
|
Software Zen: delete this;
|
|
|
|
|
|
Wow, bit of a stretch. Nice try though
|
|
|
|
|
You seem to be a Comma Chameleon.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
|
Gary Wheeler wrote: Any UNICODE experts here?
Dunno if I'm an expert, but I do know the difference between UTF-8, UTF-16, UTF-32, etc. and what a code page is actually used for (for non-Unicode).
Gary Wheeler wrote: If there are, are there different code points for each type of comma?
If it's a different glyph it's always a different code point. An easy way to verify this is to copy and paste any text you want into a text file, save it as Unicode, and inspect the text file in a hex editor.
Edit: Just read the comic after writing this  , he's using the same comma for the comic strip. He's just being silly with all the crap we go through to not agree on stuff.
Jeremy Falcon
modified 3hrs 5mins ago.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
