|
If you're working with a government agency I think you'll find this transcends fields.
The attitude of working lights on at 9 lights off at 5, and not caring more than you're being paid to care is a foreign concept to many of us working in software development, but it is de rigueur in government, at least in the states.
I think part of it is the methodical yet inflexible way they do performance reviews. You simply have to check all the boxes, and you don't really get rewarded for going "above and beyond" - you get rewarded for seniority, which leads to a lot of people simply keeping their heads down.
I don't think it's all a bad thing. A lot of private sector jobs have a culture that "rewards extra effort" but what it eventually devolves to (if it ever was anything else) is a culture of overworking employees. That's almost impossible to do when you don't reward going above and beyond.
To err is human. Fortune favors the monsters.
|
|
|
|
|
I agree, and I dont think there is much difference with gov't agencies here in Canada either.
In a similar vein, I find It shops that are unionized, even in the private sector, have a very similar mentality. I view myself as a professional, and work hard to keep my skills up to date and make an effort to keep up with technology changes. But I find a lot of unionized IT workers take it for granted that the company or agency they are working for will provide the time and money to train them.
I used to MS myself as you did I believe, and I remember working 14 hour days to meet goals and such. Destroyed my marriage in the end. Now I work as a contractor, and I find it much more rewarding. And I get paid for all my efforts. I would have to be given a pretty lucrative offer to go back to being an employee again.
|
|
|
|
|
Assuming it's in source control, why would anyone need to "take a backup"? 
Sounds like the developer who did this needs to learn about branching...
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Exactly. Mind you, some of this code is really old, and I think they started with Visual SourceSafe which had a lot of problems.
There are literally hundreds of these repos, and we use a number of automated processes to scan and report on these projects. Having the else extraneous projects in here causes all sorts of false positives as to the state of the code. It's important to have accurate reporting on all of these, as it impacts budgets and allocation time and developer resources to address these.
But as I said earlier, there should be some level of common sense on cleaning this up. As senior-level developers, there should be a trust that we can address these things without requiring convening a committee, schedule meetings, and getting senior management to make a decision for us.
This is just another form of YAGNI, but instead of adding code that isn't going to be used, it is removing code that is no longer used. And as developers we should address technical debt to clean up up any project we are working on. I liken this to the Boy Scouts, where we should leave the campsite/project cleaner and in better shape than we found it.
It is very common here for multiple teams to work on a single project. Add to that employee churn. So making sure that the code is a clean, concise and understandable is important for whoever has to look at the project the next time around.
|
|
|
|
|
by any chance do you work at the IRS?
[^]
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
No, this would be a Canadian government agency....
|
|
|
|
|
Close enough 
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
|
seems like a bunch of babies
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
Yep, I can hear it now:
'FFS, It's a ![Elephant | [mastadon]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/elephant.gif) ing backup! If YAGNI just get rid of it and quit wasting my time!'
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
Well, that's the thing. It will still exist in the repo, but people don't have to keep "tripping" over it, wondering why it is there. It isn't like it is forever lost....
|
|
|
|
|
It will eventually be forgotten, but that is the way of software. No one will know it is there in the repo.
This seems like more of a labeling situation than a branch.
With this team, if they had created a branch, then no one would have the guts to merge it back to the mainline.
|
|
|
|
|
Andreas Mertens wrote: Whatever happened to developers taking responsibility and making informed decisions?
Informed decision of course is based on understanding that the point of the company (lets use that as the stand in for whatever the organization might be) is not to 'write code'.
But rather to provide a solution that meets the needs of the company. And doing so in a way which enhances the actual goals of the company. Company goals can include things like costs (storage, maintenance, etc), performance, regulatory guidelines, customer needs and desires, higher management goals, marketing needs, etc.
So how does deleting it meets the company goals?
Now one can make the argument that cleaning it up increases some developers morale. Morale is important since it impacts retention. But could be some other developers that might have some concern, especially if the system is complex, that deleting this might cause problems. And without some other specific company goal being met it just is not worth that risk.
|
|
|
|
|
|
That's truly nutty.
Check out the name of the 4th param to the other make unique filename function:
BOOL PathMakeUniqueName(
[out] PWSTR pszUniqueName,
UINT cchMax,
[in] PCWSTR pszTemplate,
[in, optional] PCWSTR pszLongPlate,
[in, optional] PCWSTR pszDir
);
Long Pointer to a null terminated string which is the name of a Plate??
I think they meant Template.
|
|
|
|
|
My understanding is that the 3rd parameter was used for short 8.3 filenames and the 4th for the long filenames. Probably someone was "witty" and invented "longplate" to differentiate from "template".
Mircea
|
|
|
|
|
Ooh! A punster! Very nice 
|
|
|
|
|
Most probably a variant to template. It will pretty neat in a medieval game dev scenario :)
|
|
|
|
|
History:
This was part of a batch of embarrassing internal junk, that lawyers forced to document as part of the DoJ consent decree in 2001. Basically, various API surface in Windows (mostly helper functions in Shell32.dll) that other products (mostly Office) were calling.
It was never intended to see light of day.. obviously, it was the result of some dev who rotated from one org to another, and copy-pasted some helper function code from one product repo to another.
I don't recall any of those lawyer-documented functions doing anything meaningful (that couldn't be replicated in user-mode code using existing Win32 APIs). But, try explaining that to DoJ lawyers..
|
|
|
|
|
I believe you'll find this interesting and a possible discussion.
But, also, I ain't too smart so I may just not be seeing something.
I'm using the cutting edge latest version of C# 10 (in .NET Core 6.0.2 web api I'm building).
I'm saving data to a sqlite database & I have some code where I want to allow the value to be null (inserted into the db) if hte user doesn't supply that data.
sqliteProvider.command.Parameters.AddWithValue("$screenName", task.screenName);
task.screenName is a nullable string.
Null This, Null That -- There are different kinds of null
However, if the value is actually a null string because the user has opted to not provide the value then I need to actually insert a System.DbNull.Value into the databse -- that's a true DBNull -- not the String null which the db chokes on.
The New Null Operators
So, I'm new & I'm hip to the scene of these null coalescing (??= ??), Elvis operators (?: ) and all that stuff, you dig man?
But it's a no-go.
Null Still Ate My Code
Here's what I wanted.
I wanted to call the AddWithValue() with the String value when the nullable string (task.screenName) isn't null...
....and I wanted to call AddWithValue() with a System.DbNull.Value (so null would be properly passed and inserted into the db) when the nullable String is null.
I was hoping for something like:
sqliteProvider.command.Parameters.AddWithValue("$screenName", task.screenName ?? System.DbNull.Value);
I was hoping it would say, "if the String is null, then use the System.DBNull.Value.
Two Different Types
But, like, far out and way out man. It ain't happening, because those are two different types.
And, dig it, to get these null operators to work, they have to be the same type.
So I had to write a method:
private Object convertDbNull(String? s){
if (s == null){
return System.DBNull.Value;
}
return s;
}
Then call my code like this:
sqliteProvider.command.Parameters.AddWithValue("$screenName",convertDbNull(task.ScreenName));
It'll return the valid String (when not null) or it'll return the System.DBNull.Value (when the string is null).
Surely, I'm Missing Some Super Special Null Operator??
If you have a better way where I can use one of the new null operators, please, please lay it on me. 
So the Multi-Billion-dollar Null Problem still exists, apparently. (https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/[^])
I eagerly await your input on this (seriously). 
modified 22-Feb-22 17:39pm.
|
|
|
|
|
sqliteProvider.command.Parameters.AddWithValue("$screenName", (object) task.screenName ?? System.DbNull.Value);
That should work. C# won't coerce a type (even if it's valid) to a type not present in the expression. Here it sees string and DBNull, so even though object is a valid base for them, object isn't available unless you explicitly opt-in. That's my understanding at least 
EDIT: You might need a ? for the cast. Unsure since I'm still on an older version of C# so I haven't had to deal with that new stuff yet.
|
|
|
|
|
Very good point and thanks for posting.
I will try this out right now and let you know.
|
|
|
|
|
Oh my gosh!! I was so close!!!
That works -- well it compiles anyways. I will test to insure that it definitely does what I expect, but it looks good:
sqliteProvider.command.Parameters.AddWithValue("$screenName",(object)task.ScreenName ?? System.DBNull.Value);
Wow!
confirmed!! I built it and ran it and it works.
I'm so glad I ranted.
Thanks again.
|
|
|
|
|
That's an API problem, not really related to null or not null, but the fact that .NET DB drivers assume "null" as unset, and DBNull.Value as real null (WPF did it a little better, as we have Unset as a separate item, and null really means null).
You can probably create a helper/extension method that converts null to DBNull.Value and it should work fine.
I also consider it very bad that IDataParameter always box value types. It shouldn't need to do it, as I can clearly tell by working on C++ drivers that primitive types can just be primitive types and never "boxed" or similar there.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
