|
|
|
I actually just finished making one of these for a science center for kids. It was a fun project, the end result is really cool.
|
|
|
|
|
While this is definitely "Geek Dad of the Year" material right here, it's a bit like giving your wife a diamond tennis bracelet for your one year anniversary... Setting the bar really high.
|
|
|
|
|
i just wanted to say. nothing personal about the hal. [redacted] just told me to rewrite it and thats what im doing. i actually think you have a lot of good ideas when it comes to programming, its just that is very beginner un-friendly.
So, let's see. A system that is:
- modular
- micro-services architecture
- has to deal with asynchronous events on non-UI threads from hardware
- uses a publisher/subscriber (of my own design) to queue work (synchronously or asynchronously), distribute messages to all receivers, and handles exceptions by the receiver
- includes a logging module to PaperTrailApp
- includes an email module for critical exceptions
- has to interface to CefSharp
- has to deal with all sorts of hardware, from ATM's to desktop devices (some of which are brain dead)
- supports mocking hardware by simply swapping out the real module in the config file with the mock module
...is supposed to be "beginner friendly"?
ok, we could:
- make it monolithic
- handle async processing somehow (not sure what they have in mind)
- make it non-modular
- throw out the mocking features
- throw out the logging
- throw out all but the 3 devices their trying to support
and...
- re-implement it in F#
- use reactive extensions
- god knows what other fancy kruft
and that WILL be beginner friendly.
As Ryan Peden so accurately stated[^]:
but weak or non-existent technical leaders...are the ultimate cause.
And as to i actually think you have a lot of good ideas when it comes to programming coming from the newbie, well, I had some choice words I won't repeat here.
Marc
|
|
|
|
|
Why do I get the feeling that we'll be getting CODZ PLZZZZZ!!! messages from these kiddies?
I think most of us have been in similar situations, Marc.
Hold your temper and your tongue, and never respond with anything that can be misinterpreted (translation: used against you by useless ****s whose only real skill is in talking to the boss).
You're already on the back foot, so this is one of those situations where being honest would be a bad thing.
And, as I say, be ready to gracefully pick up the pieces, when it all falls apart.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
It would be funny if it wasn't causing you grief. Having to deal with code-minkeys is a pain especially when the manager wouldn't know the difference between a line of code and the perforations in toilet paper.
You seem like a pretty patient guy: just hold your tongue and wait it out... arrogance and inexperience always come a cropper! (I know that from when I was arrogant and inexperienced  )
|
|
|
|
|
R. Giskard Reventlov wrote: just hold your tongue and wait it out.
I've been doing that except Friday I fell off the wagon. 
Marc
|
|
|
|
|
Now THAT's the part I want to know about.
But then I was required to go to sensitivity training because I told a contractor that flipping the way we thought about a feature on it's head to accommodate that one vendor was stupid. Most of the industry said X is an upgrade but one vendor thought of the same thing as a discount and that did effect the way information was presented.
I still stand behind the thought nearly 20 years later. The contractor had no loyalty to the company I was working for and that was what I was defending.
|
|
|
|
|
When dealing with them... think about what you were like at their age. How would you have responded to this situation at that time?
What can you teach them that is.. beneficial to all?
Mentor them; they didn't put you in the position you find yourself in - the project manager did.
|
|
|
|
|
Tim Carmichael wrote: think about what you were like at their age. How would you have responded to this situation at that time?
Actually, I do. It's a different world. When I was 18, I went to Commodore PET meetings and ooh'd and aah'd at the amazing things people were doing.
My neighbor (who I ended up working for) hammered into me the necessity of precise communication. He also introduced me to 6502 assembly language (at that point, it had to be entered as integer opcodes in a DATA statement, or something like that.)
I also worked with other programmers developing games on the C64, they were older, and we learned stuff from each other. Later, I had the great opportunity to work with hardware guys, and learned a ton of stuff, and wrote a test utility that proved to them that there was a race condition on the chip select for the upper/lower 8 bytes of the 16 byte address bus -- which didn't show up in the wirewrap prototype because the wire was longer!!! That earned me the respect of the hardware guys, who before then thought software was always the problem.
Tim Carmichael wrote: Mentor them
The problem is, nowadays, these youngin's don't want to be mentored. They think they know a lot of stuff already, and sure, they have some interesting projects on GitHub, and they DO know some things, but the important things, like design, teamwork, learning from others, just doesn't seem to exist anymore. In some ways, I think the open source community and the explosion of "simple" languages has made it easier to go into peacock behavior.
Marc
|
|
|
|
|
Marc Clifton wrote: its just that is very beginner un-friendly
How can they be expected to learn if they must have their hands held?
Scripting is beginner friendly.
Coding is the intermediate.
Programming is hard and requires precision and knowledge.
The boss should be asking you to bring them up to speed and not regressing to their level. 
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Foothill wrote: The boss should be asking you to bring them up to speed and not regressing to their level.
That was the idea, but because the boss doesn't understand the tech, when the junior says "wow, this stuff is complicated", well, that's when the fat lady sings. It's all over.
Marc
|
|
|
|
|
I've been in the same case a couple of times.
Once (2008 or so) I wrote an application that would use WinForms and web services. I also wrote the simplest possible unit tests.
Then I was lucky enough to get the help from 2 juniors who didn't have a clue of what they were doing. So I asked them to finish some of the unit tests (a couple of lines each). After 3 weeks they still couldn't so it was decided that unit testing was too hard.
You can imagine how they felt about them "web services", exotic witchery...
So I quit the project.
Anyway, it is important to document the choices that you make in the project. Make sure that you communicate problems that you foresee beforehand, so that you don't fall into a game of "I told you so" later.
Courage!
|
|
|
|
|
One wonders who you are supposed to be coding for, the client or the kiddies. Is your code supposed to be beginner friendly or get the job done.
Having said that I can see the point from the other side, someone, the kiddies, will need to support the app and his current crop seem to be incapable of doing so!
I have had devs who over engineer/complicate a solution for no real benefit (that I could see).
I have one MVC app that no one is game to touch as the guy who built it made it so complex with such a plethora of technologies, all the latest stuff, that it is unsupportable and will need to be redone in a simpler design.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I go with the attitude of the kiddies. I remember onetime a consultant who built a library that do geological field mapping which suppose to be easily maintainable. Unfortunately he make the entire library so complex that not body could like it and finally abandoned to be done by in house engineers.
If you think from owner of the app perspective, they should be comfortable in what language learning, framework,... is being built. I see what they mention in your case is not appealing.
modified 2-Aug-16 13:20pm.
|
|
|
|
|
i love the way explained things. got it really really fast!
|
|
|
|
|
That makes me think of my current project
- only 128 pages of specifications
- different design on iOS and Android, great emphasis on native and perfect user experience
- multilingual
- must be finished last week
|
|
|
|
|
From the few update I have followed.. the crux of the problem seems that project managers, you and other developers are at odds.
Whether or not your design is the bestest and simplest... You being at odds with other developer and manager is going to cause untold amount of pain.
Now, maybe this entirely your fault, or maybe the young developer are both technically stupid but better politically, or maybe the project manager is being stupid here pitting you against the young developer with the vain hope of a miracle...
At any rate as long as this political dysfunction remains... untold amount of pain will ensue...
That said I am not very good politically either... But I would advise a political approach to that problem...
|
|
|
|
|
Have you considered issuing a coloring book edition of the interface specification? 
Will Rogers never met me.
|
|
|
|
|
Hi Marc,
To me this latest chapter in the on-going psychodrama just confirms, unfortunately, that you are between Scylla and Charybdis, the rock and the hard place.
If you do not have support, and acknowledgement of your status, from the manager, and the juniors don't recognize your experience and authority, I don't think there is a positive outcome possible.
Wish I could say something more than: "commiseration is" ! 
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
|
|
|
|
|
That's kinda demoralising.
Is there a planning discussion you can refer to that points out that the decisions you made were the logical ones and the agreed ones? Or did you need to resort to the "Do you want this complex system be approachable by beginners, or do you want it to work properly, safely and efficiently and be easily maintained and extended?"
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: Is there a planning discussion
We can stop at the word "planning".
Chris Maunder wrote: Or did you need to resort to the "Do you want this complex system be approachable by beginners, or do you want it to work properly, safely and efficiently and be easily maintained and extended?"
Yes.
But, as elsewhere astutely stated, we seem to be coding to the beginner rather than meeting the application requirements, which are driven by the never planned/discussed real world requirements.
What seems to be missing from the CTO's understanding is that, having been through the ringer once with a rewrite of the VB crap that I was brought in to rewrite, and then really learning the business domain, I wrote the next iteration to really address those domain issues, based on my experiences working not just with the tech, but also talking a lot to customers and the tech support people and realizing the kind of tooling we need for responsive, well responses to customer issues, whether they're the customer doing something stupid, or network outages, or hardware failures, or bugs in my app.
Marc
|
|
|
|
|
Ah, I see your problem.
You wrote what was needed.
You were meant to write what you were told to write.
Silly boy!
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: You were meant to write what you were told to write.
Unfortunately I was not told to write code that was "beginner-friendly." That was not in the requirements.
If it was, I would have used VB. 
Marc
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
