Lol the epic points vs. hours debate. The stupidest part of that to me is when they want to define a task solely by some mythical generic dev effort. Meanwhile in the real world I know if Sean gets this task it will take half a day. If we give it to Mark it will take approximately infinite hours.

But I agree cards done right are good. When I have a bunch of well-defined tasks in my queue I'm a lot more motivated to knock them out than if I have some ill-defined blob of stuff to do.

Basically imo, if you use the tracking stuff as a tool it can be very helpful. Just don't get too deep down the rabbit hole where you try to bypass the art of a good lead knowing who should work on what and when.

Not just developer skills, but which stuff is a known problem and which stuff could blossom into more work than expected. There's nothing worse than a manager micro-managing this stuff because they want some feature to put on their slide, when I know as a dev lead we really need to work on something less sexy first to minimize risk.

And other stuff I'm forgetting that goes into the equation.

That's a Scrum But holdover from the place I learned it. They put hours on tasks and used hours in the burn down charts but didn't use the hours for anything else, specifically how long it took to get things done. Stand-ups were essentially when devs updated the team on the time remaining on the tasks they had in progress.

Probably easier for the dev managers to wrap their heads around than trying to figure out what was left to do from tasks with no sizing associated with them.

We had a recent big launch and my boss went to schedule a retrospective for it and found that one had already been held.

That hadn't included anyone from engineering.

Weird, right?

A lot depended on the story as well, we had lots of stories at the level of a single task, the "do it" task.

Was the biggest finding a lack of input from engineering...

I'm going to go out on a limb and say no. Back pats all around presumably.

Better than when the stakeholders all ***** about not getting the features they wanted when they wanted them.

I have so much to say about this project. Let's start with this:

The project had a hard deadline, which is always a terrible idea. We were going to announce/demo it at a major conference. Initially I was OK with this because I was *done* 3 months before the conference but that was before they decided to start from scratch again 3 more times.

Actually let's continue with this:

The project was divided into 2 rough parts. One part was all me, the other part was 10% me and 90% other people. I had the demo for my part worked out and tested, and had gone through it with the people who would be demoing it. Great. On the morning of the demo I idly asked the other group what their demo was composed of.

That was when I found out that it was composed of a feature that AFAIK was not included in the release plan (i.e. I hadn't done it). A bad misunderstanding - maybe even my fault.

But this means that they had planned to do a demo of something they hadn't EVEN TRIED before hand. WTF! Who does that? So 20 minutes before the demo I'm coding this feature and releasing it.

I hated when salespeople called support because they were in the middle of a demo that they hadn't requested data for or practiced the night before when we could something. Even after they had been burned by this same thing before hand. Very frustrating.

I once fixed a bug to get a demo working while my screen was projected and everyone was watching. Don't try this at home kids.

I like to think of myself as the Alex Honhold of programming.

I did a demo not long ago and I was demoing running an "agent" on remote machines and seeing them show up in the interface. I needed another machine to add and decided to use one on my home network.

After the fact I realized it's name showed up as "lolbutts"

I have since renamed that machine.

Now it's called "uranus"

loluranus

favorite piece from dip**** ******* moron proff from my ~sophomore level programming class:

today in lab he has us implement a program that takes in polish notation from stdin and outputs a result. ok. pretty easy, just use a stack. I wrote my own stack and implemented the program in like 20 mins.

spend nearly the rest of the lab session (you fail if you dont finish by the end) trying to figure out why his second test case keeps failing. One, it has multiple spots where double/triple spaces are embedded in it, which ok, is kind of my bad for using strtok() improperly.

but then it still fails after i catch that. wtf?? one of his test cases has an integer overflow, and the problem specifically states we only are supposed to use 32 bit signed integers.

luckily i was so sure something was wrong with the test case that i didnt even bother checking if something was wrong with my logic. this class is filled with stupid **** like this. I had to argue with the TA about it, and he said "something was wrong with my intermediate calculation" and i had to show him how it was literally impossible to get the result without overflow as the problem was written so he let me use long long int instead.

my other thing - he gave us a quiz today where we basically the expected answer was to write how linux system calls to read() are faster than fgetc and fgets which is FLAT OUT ****ING WRONG I'm like nearly 1000% sure. But he had us implement a program where this is indeed true, but it's dependent on a lot of variables and the specific environment/compiler you're using.

sorry for the rant this has been a long ass week.

this is the 5 line limit professor***

which, my strategy with that has become: write a working program and then just refactor after it's done.

When I was in sales I demo'd web apps that were completely broken with a golden path using chrome dev tools. Just don't close the tab or things might get embarrassing.

Yeah I'm pretty sure fgetc is nearly always faster. It might be counter-intuitive but it uses buffering under the covers. You can increase the buffer size by messing with the underlying fd. I'd be curious when read() is faster.

I'm not really sure what this means. "Golden path?"

"Golden path" means the path through the application where bugs are not triggered/ features that are only works in progress look complete/ etc.

Stuff like broken UI components, that you could tweak in dev tools to hide, or fix it enough to pass a quick glance.

I see. My most recent demo was demoing both an agent that gets installed on customer computers, and a UI that shows the collected data. We ended up completely mocking the agent, event though it works, because triggering specific responses as deemed to be "too difficult" or unreliable to demo. This horrified a fellow developer - that the demo was essentially fake.

I was OK with this. The technology works, but creating a realistic demo of it is a pain in the ass. Either you need to install malware or go to a shell and create some traffic that looks and acts like malware. The sales guys didn't want to do that so I made a program that acts like it receives those malware signals. Smoke and mirrors I guess, except that behind it, it does actually work.

Right - and it uses a buffer at the user level and doesnt dip into the kernel very much.

The read() implementation used a buffer of size BUFSIZ which is a constant that’s OS dependent (i think) but i think it’s like 4096 bytes.

So if fgetc’s buffer is a lot smaller than that that could be why. But read() with the max buffer was definitely a lot faster. Which is a deceptive and stupid outcome that the proff is kind of an idiot for, he didnt explain the underlying mechanics at all and now there’s going to be a whole class of graduating CS majors that think system calls are the correct way to do I/O

on further research, because this is really irritating me, I think fgetc uses BUFSIZ for it's buffer as well, so I think it's going to make the same number of system calls as just using read() with the max buffer size.

that only leaves the overhead of calling fgetc for each byte in your input. I'd be willing to wager money that fread() is faster than the system call method.

it's a dumb problem with incorrect conclusions. the guy is such a smarmy jackass and has really gotten under my skin for some reason

"golden path" reminds me of a demo i had to give for my software engineering class 3 years ago. My application worked pretty well, but there were very specific paths you could take through the program that would break it completely and i didnt have enough time to fix everything, and since I coded and tested the entire project, I was the only one that knew about them.

for some reason it was decided the dumbest person in the group was gonna demo and i told her very specifically the things she absolutely shouldnt do in a specific order. she proceeds to start to do them and i had to quickly (as casually as possible) run over and click out of something a few times so it wouldnt break completely.

I used to teach a programming class and I always looked for a few things in programs. In C++ for example I would look for cout calls that were not required, because these would often cover up memory corruption mistakes. The student wouldn't know WHY, but he knew if he put a cout here or there the program would stop crashing.