|
I think you've finally crossed the
here.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
What's the <div>?
New version: WinHeist Version 2.2.2 Beta I told my psychiatrist that I was hearing voices in my head. He said you don't have a psychiatrist!
|
|
|
|
|
|
|
The --staged one cost me several hours, one week.
Useful page. He should do more.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Over the last few months:
Developer A has written the back-end Django models, unit tests, and third party e-commerce integration, with unit tests.
Two weeks to go:
Developer B has written the back-end Django REST endpoints and unit tests to interface with Developer A's code.
One week to go:
Developer A and B work together to fix problems found in the business logic for managing the models and third party e-commerce and update the unit tests for both models and endpoints.
Four days to go:
Developer C (as in CTO) implements Javascript client-side models and Backbone AJAX functions to call endpoints but no unit tests.
Three days to go:
Developer B finally gets to integrate the AJAX calls into a complicated e-commerce workflow and discovers problems with C's work, which get fixed. Developer B also fixes minor assumptions made when he created the workflows that are now incorrect now that he sees the actual test data coming from the back-end and e-commerce test endpoints.
Two days to go:
With the UI now calling the back-end, additional problems are discovered on the back a) not covered by the unit tests and b) because the e-commerce test endpoints require specific test data sets that were not communicated. Easy to fix.
At this point, the UI works, and Developer B uploads some custom hardware screens to the hardware at the actual (remote) demo location...
BUT:
a) Developer A and B are running local VM-hosted instances of the server.
b) Developer B is the only one with the rest of the hardware needed for the UI to actually test against real hardware, rather than mock data, and is actually missing one major component, the MICR (check routing/acct #) reader.
c) Developer B Slacks Developer C that everything is working locally, but because the server is not yet hosted somewhere on the cloud, Developer C needs to get that set up.
One day to go:
Developer C Slacks Developer B that the server is now hosted on the cloud.
Developer B can't log in because the account registration email links to the old server. Easy to fix.
6 hours to go:
Developer C gets around to tasking some locally to test the app running against the cloud server and all the hardware.
Newbie 1 plugs in hardware. PC says "Power Surge Detected on USB Port"
5 hours to go:
Powered USB hub located, system fully rebooted, hardware has "moved" on its COM port assignments, no problem, it's a configuration change (auto-detection doesn't work because sending "are you there?" queries over USB-COM locks up hardware the message isn't intended for.)
4 hours to go:
Problems are discovered with the MICR reader. Developer B, who's never actually had a chance to test his code against the real hardware, discovers some things about the data stream that result in a quick refactoring of the code, ends up coding some stupid logic errors, fixes them, and all is well with that piece of hardware.
3 hours to go:
The other piece of hardware doesn't work. No custom prompt screens are displayed. Newbie 1 tells Developer B "Oh, we moved that unit to another computer and plugged in a brand new unit on this computer." Annoying, because the test fixture that Developer B was working with is in someone's office and supposedly considered "do not touch" for the explicit reason of having a stable demo'able system. Developer B uploads the screens to the new hardware, and all is well again.
2 hours to go:
Newbie 1 tests and the workflows fail. The server is throwing exceptions that Developer A and B have never seen with the unit tests or local VM-based server testing. Developer B identifies some of the errors as incomplete registration, where the database now has essentially corrupt data because it persisted some information, faulted, and therefore didn't persist other information. Fault tolerance was not part of the unit test suite, and clearly the model management needs to be improved, but given good data, we should get good results, at least for demo purposes.
Newbie 2 bitches to Developer B that he is using clear text for his GitHub account (this is because Developer B is using GitHub to update the binaries because remote FTP is so freaking slow.) How is this clear text password being sent? Oh, it's because Developer B is remotely connecting, using Kaseya, into the machine, and typing it into a command line prompt when "git pull" asks for the password. Really? Clear text?
One hour to go:
Developer B asks Developer C to reset the database (this is on a clean server, remember, so it's easy to do, supposedly.) Developer C bitches about accessing the database directly because their might be foreign key constraints, we never access the database directly, we use models. Database is finally cleaned.
Newbie 1 does more tests, still strange errors. Developer B asks to see logs from the server. Newbie 2 bitches to Developer B:
Developer C just said that he did not write any of that js, apparently this is your js
if its a problem with js, its your js
Developer B tells Newbie 2 to elephant off, and that if he doesn't have something useful to contribute, to please "shut up."
Developer C goes to get a beer and comes back three hours later.
Developer B suggests to Newbie 1, that when Developer C comes back, he provides:
1) a REST call to the server that can be made to clean the DB
2) implement auto-pull when source code changes are made.
Why? Because only Developer C can clean the DB and do pulls from the repo to update the DB, but since he's out having a beer it sort of stops the rest of us from testing against a clean baseline.
Zero hour:
Developer C throws Developer A under the bus, blaming the back-end model management and e-commerce inteface code.
In the meantime, Developer B wonders if Developer C will ever get around to styling the UI (a task that was supposed to have been completed two weeks ago) because the UI still has all the buttons to simulate the server responses that he had to create when the server pieces were missing!
Developer B also wonders if he'll get fired for his elephant comment, and will do a ![Jig | [Dance]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/jig.gif) if he does.
Now the quiz: Which one am I, Developer A or Developer B? There should be enough clues!
Marc
|
|
|
|
|
B. Now where's my prize? 
|
|
|
|
|
Vincent Maverick Durano wrote: B. Now where's my prize?
Correct! No prize was stated. 
Marc
|
|
|
|
|
 did you get fired? 
|
|
|
|
|
Marc Clifton wrote: Which one am I
Developer C, surely? 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
 It seems that way.
|
|
|
|
|
I'd rather be the developer who went and got beer.
This space for rent
|
|
|
|
|
Reader T notes that, as per the narrative, Developer C implemented Javascript client-side models.
So, what does the version control log show of whom checked in what?
|
|
|
|
|
Tim Carmichael wrote: So, what does the version control log show of whom checked in what?
Let's all just concentrate on getting the job finished first, and then apportion blame when we have time to be really, really nasty about it at great length.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I love this post. It's so universal!
|
|
|
|
|
Both? All? None?
To be honest, I have conversations like this with myself all the time. That is why I have my office in a safe location, away from the general public. Just saying...  
|
|
|
|
|
TRICK QUESTION! You're obviously the newbie.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
| B
... such stuff as dreams are made on
|
|
|
|
|
In your normal job, you're Newbie 1. When you step into the phone booth and put the cape on you become Newbie 2. 
|
|
|
|
|
Source version history tell the truth. Or else you're going to have "He did it, No She did it" old days drama.
|
|
|
|
|
All of the above. The first rule of Fight Club is: You do not talk about Fight Club.
|
|
|
|
|
B. I have no doubt.
Michael Martin
Australia
"I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible."
- Mr.Prakash One Fine Saturday. 24/04/2004
|
|
|
|
|
I believe that in this psychodrama, you are "A."
But, perhaps this article might help you understand C.'s behavior and "state:" [^].
commiseration is, Bill
«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
modified 13-Sep-16 15:05pm.
|
|
|
|
|
BillWoodruff wrote: I believe that in this psychodrama, you are "A."
Nope. B. I would never tell someone "it's your code, it's your bug." And I have temper, hence the elephant comment.
Amusing article on C!
Marc
|
|
|
|
|
Interesting, Marc; I couldn't imagine you telling a "newbie:" "... elephant off, and that if he doesn't have something useful to contribute, to please 'shut up.' "
When I read this: "Newbie 2 bitches to Developer B: 'Developer C just said that he did not write any of that js, apparently this is your js ... if its a problem with js, its your js' " That says to me that it is C who uses the phrase, as reported to B by Newbie 2.
There's virtually no comments by A, and I assumed you did back-end, and, further assumed, that if anyone would get thrown under the bus by C, it would be you ... based on your previous blow-by-blows.
«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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
