|
We have enough problems just keeping the current system running in the face of all of the security squeezes.
Constant screw tightening.
|
|
|
|
|
The last project I worked on they tried that. But they soon abandoned the idea when they realised how much time was being wasted.
|
|
|
|
|
85% reading code and debugging to understand how the system works and how I should implement new changes so as to avoid breaking anything.
14% in meetings, admin, training, communications, reading documentation or articles related to what I am working on.
1% writing actual code.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Sounds like greenfield project and junior team.
Dependency injection is like air for me, we don't have to discuss anything it is just there and we just use it. Maybe if some junior joins we have to explain stuff but for any mid/senior we just don't talk. Same with patterns we don't build framework so we don't deal with god know what level of abstractions so we mostly build features.
On the other hand there are discussions on interface as everyone feels like they should have an opinion if button should be more to the right or more to the left - but backend is solved problem for me at this point for a web application in .NET/C#.
|
|
|
|
|
I'm proud to say it's probably about 99% coding in my company 
Not for me of course, but I'm sales, marketing, HR, finance... 
|
|
|
|
|
"Keep in mind, I'm an older version,"
At least in the far past problems that were solved by computers were significantly less complex.
"85% discussions/meetings about"
Can't speak to your current work situation but certainly I see value is making sure requirements (whatever form they take) are fully specified and understood. Then designs follow from that. The more complexity then the more important that becomes. Neither of those involve throwing code.
I certainly would not want to use a bridge where they started throwing steel/concrete on day one of the contract being signed.
"Code review and refactoring ... and testing the 'whole sh*t' again"
Yes code review is important. Some examples.
- A senior developer that could not seem to grasp how distributed applications worked with databases and was trying to use thread locks to control something that could only be handled by a database transaction. This happened multiple times.
- Multiple different senior developers that wrote C# linq expressions to span/iterate through the entire hash table to do a key look up.
- Senior developer that rewrote a simple switch/case factor pattern (incorrectly) to avoid a static code check which resulted in a production exception.
Testing of course is important when code changes.
"15% Implementing the customer's request"
There is of course no guarantee that implementing processes will be done even close to correct. Not to mention other factors such as the following.
- Personality problems.
- Despite claims that every single company has above average programmers actual probability insures that there will in fact be below average programmers.
- Management blame gaming which makes employees hyper-sensitive to touching anything.
- Management blame gaming which makes employees hyper-sensitive to incomplete requirements.
I worked with a Director recently that seemed to think that every problem could/would be solved by throwing more threads at the problem. Despite him have no actual technical experience with the product. So of course that meant threads got added.
|
|
|
|
|
"At least in the far past problems that were solved by computers were significantly less complex."
Seriously? I'm looking at the Space Program, etc. You'd be amazed what was done in electronic warfare with Z8 processors. I'm interested in you elaborating a bit on this. I agree that we're doing some cutting edge stuff with gene analysis, etc., but I don't see the problem space getting more complicated. Honest question.
"but certainly I see value in making sure requirements (whatever form they take) are fully specified and understood. Then designs follow from that."
Curious if you ever read the Extreme Programming book - the original? I took a few nuggets from it as a development manager. The biggest one was that the customer really has no idea specifically what they want when it comes to a software system or application. They view it as solving a problem. I believe solving the problem is where the requirements should be. Defining requirements into the minutia will simply kill the project before making any progress. Let smart people make smart decisions. I'm seeing this now at the company a consult with. They are so focused on making sure the requirements are in place that if the developers were to wait for them, the project would never be delivered on their magic schedule. Mind you, marketing wants something by the end of the year, the requirements are not complete, and we're already writing code. 
The other thing I pulled from this book is unit tests. If a team can build a test suite that gives them test confidence in the code base, much freedom will occur. In one case in my 40+ years of engineering, mainly in embedded systems and what not, have I seen a good regression test. It took hardware to validate the product under test, but if we made changes to very complex areas, we threw it against the test system. As far as HMI stuff, I've never seen it done.
"I certainly would not want to use a bridge where they started throwing steel/concrete on day one of the contract being signed."
This is where patterns come into play. We build bridges all the time. We do the same thing in other areas. Everyone knows what a bridge is supposed to do. You already have your high level requirements . What is the span of the bridge? How much load must it carry, etc. These are well understood. In software, just about every project is new and fancy. In my world, we're developing a product that performs the same basic function as the previous 3 products over the past 30 years. The concepts are not difficult but due to technology, implementation can be. But our pattern is what was developed 30 years ago - the problem we're solving (it will never go away) is still the same.
I suspect that 90% (I made that up) of new software is solving the same problem in the problem space.
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.
|
|
|
|
|
charlieg wrote: but I don't see the problem space getting more complicated. Honest question.
And no one has been back to the moon since.
Exceptions do not make the rule.
In general now on average the scope of applications and services that need to be created are more complex than those that needed to be created long ago.
charlieg wrote: Curious if you ever read the Extreme Programming book
yes. Along with probably hundreds of other books and decades of magazines.
(lets see ... 20 years of one text book a month ... 20 x 12 = 240. Yep hundreds.)
charlieg wrote: Let smart people make smart decisions
Programmers are not 'smart' people. They are average people. That is how normal distribution curves work.
I have seen programmers do very stupid things.
Process reduces the likelihood of that making its way to production. Doesn't eliminate it. Might not even be significant. But at least if it is not followed then one can point out the problem.
charlieg wrote: 40+ years of engineering
I also have that much experience. Most of the time working on complex systems, either with the explicit or implicit role of architect in multiple problem domain spaces. That includes start ups with less than 5 people to one company that had 2,000 developers.
charlieg wrote: The other thing I pulled from this book is unit tests.
Just noting that I built a unit test framework before others existed.
But also not sure how this follows on from your original OP.
charlieg wrote: In software, just about every project is new and fancy.
I agree. But no idea how that relates to your original OP.
|
|
|
|
|
"Patterns" have always been considered solutions looking for problems.
Just because one uses them will not ensure that the coding will be any more efficient than quality coding by one who doesn't use them.
The idea of the use of "patterns" became ever more encouraged with the advent of the Microsoft introduction of the ASP.NET MVC paradigm in 2010.
It was BS then and it is still BS today...
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
sort of disagree. I think Patterns failed because it was applied at too low a level. It should have been left at the systems requirement level.
that said, many system processes should be standardized. Logging, diagnostics, response to h/w failures, etc. This requires good management from empowered system engineers.
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.
|
|
|
|
|
I would like to "publish" a guide to newly hired "customer service agent ".
Here is a start - in no particular order:
(do not fix it ) get a new one
it is a user's (customer's) fault
RTFM
"customer is always right " no longer applies
it is working fine here
|
|
|
|
|
Quote: it is working fine here
That's the one that gets me the most infuriated.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
... From both sides of that conversation.
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
1. Clear your cache.
2. Clear your cookies.
3. Reboot.
I've almost told some of these types to get stuffed. What stops me is knowing it's rarely their fault, but that of people who want to put customers through an escalation sequence because 80% of the calls to the help desk are from idiots.
|
|
|
|
|
Quote: What stops me is knowing it's rarely their fault, but that of people who want to put customers through an escalation sequence because 80% of the calls to the help desk are from idiots.
What I can perfectly understand, but at least they should have a shortcut for issues from people that are calmed, polite and look like they know what they are saying.
Instead of having to waste hours / days with people that hasn't an ![Elephant | [mastadon]](https://www.codeproject.com/script/Forums/Images/elephant.gif) ing clue and do not trust on what you say (or they don't even know what the heck are you talking about) because the system checks and rewards time consumed and things from the database checked on the moron customer's side.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
What's interesting is that a lot of "clear your cache" is really "clear your cookies". Web browsers are pretty smart about replacing cached files. Cookies, on the other hand...
|
|
|
|
|
Greg Utas wrote: because 80% of the calls to the help desk are from idiots.
That might be low.
My most memorable experience as someone trying to help ...
Customer cussed me out after I explained he would need to turn on the computer with the switch on the side of the box. Not because he hadn't turned it on but rather because he thought it should not have an on/off button.
|
|
|
|
|
I can tell you that the manager would tell the CSR to grab a screw driver, mop or whatever. Every time; every day.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
May I submit another:
"No one else has complained about that"
(Often it's because they have experience reporting complaints and know better not to bother)
|
|
|
|
|
var nfa = FA.Parse(@"(foo|(bar)+|ba[rz])|foobar");
Console.WriteLine(nfa.ToString("e"));
(bar|barba(rba)*r|baz|foo|foobar)
It was always the loops that would just nail me to the wall.
I still have to clean up the expressions it produces but they are essentially correct!
I used the state removal method[^] but I couldn't find an adequate explanation.
Finally, I found this: GitHub - wolever/nfa2regex: Converts NFAs (and DFAs) to a regular expressions using the state removal method.[^]
It's in Go, so I taught myself some Go  Not a bad language in that it only took me a few hours from start to finish to learn enough of it and port away from it to C#.
Unfortunately when I think I am too smart for my own good I used to try to do this algorithm to remind me of my intellectual shortcomings - I no longer have that opportunity.  I guess I'll have to try LL(k) or LL(*) parsing next. The trouble with that is parser generators aren't usually good enough to make real world parsers, or the code they generate is too big. Oh well. I'll find something.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Your mind never ceases to amaze me 
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
|
|
|
|
|
I am already happy if I manage to barely understand what gets posted 
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
So am I. 
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
I know... .and please do not change
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Hopefully you have a lot more test cases.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
