Working in Development: Leaving sounds like a great decision.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Working in Development: Leaving sounds like a great decision.

«‹›12 »

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Without digressing into specific ways that CS departments may or may not meet the needs of their students, most CS departments are an absolute shitshow. As a project my final year of college, I did an assessment of the college's curriculum, working with the department secretary. We found that the department didn't even have quantitative data on the students in order to make reasonable decisions about what they should be teaching. They had no idea of who came in to gain a theoretical grounding in computation versus people who wanted to learn skills for a development job, they had no idea what outcomes were for people graduating from the program. They didn't know the math SAT scores of incoming students and they didn't even have the retention rate for how many students who declared computer science as a major were still in the program a year later. We asked to present our findings at their annual curriculum design meeting and discovered they didn't have one (they do now).

You could maybe understand this somewhere in the humanities, but this is a department whose job is literally to teach students how to use data to solve problems and they just. don't. give a poo poo.

# ¿ Feb 1, 2016 17:14

Adbot: ADBOT LOVES YOU

# ¿ May 2, 2024 06:12

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Sarcasmatron posted:

http://www.amazon.com/User-Stories-Applied-Software-Development/dp/0321205685

This one also

http://www.amazon.com/User-Story-Ma...+mapping+patton

# ¿ Feb 3, 2016 19:27

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

ChickenWing posted:

Things pissing me off:

holy fuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuck why did we take half an hour out of our 1.5 hour meeting to talk about which parts of a single 30 word blurb of text are dynamic

I really hate people who make it their meeting-mission in life to have a very long and protracted opinion on every single point

To avoid bikeshedding, we moved towards just asking developers to implement requirements however they think is appropriate. We spend less time reimplementing things that people don't like than we did talking about them before

e: and I just stumbled across this: http://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction

Vulture Culture fucked around with this message at 19:42 on Feb 5, 2016

# ¿ Feb 5, 2016 19:35

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Hughlander posted:

The inverse is just as bad. There was a group of leads/architects who insisted that all code should be self-documenting and therefore there isn't a need to comment the code base. One of them for some reason didn't see the irony of saying that at the same time that he's scratching his head over what two functions do and why they're invoked in the order they are. During the code review of said functions that he himself wrote the week before.

Dogmatism of any sort is just bad.

I always tell junior developers, "We can see the how by reading the code. Start by documenting the why."

Sometimes people make it to lead/architect without learning this

# ¿ Feb 7, 2016 19:43

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

baquerd posted:

Waterfall 2006 is generally superior to Agile anyways.

http://www.waterfall2006.com/

thanks for posting this

# ¿ Mar 7, 2016 20:53

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

ChickenWing posted:

We log work to specific jira tasks, but as far as I know nobody really cares about it so long as you don't go too wildly over the estimate without an excuse

The entire point of estimation in Agile, and people don't stress this enough, is that it forces developers to think about the time their dumb scope-creep idea actually takes before they go ahead and just do it

# ¿ Mar 7, 2016 22:51

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Our of sheer morbid curiosity, how do people in here feel about the #NoEstimates movement?

# ¿ Mar 8, 2016 18:42

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Finster Dexter posted:

I don't think any Agile implementation is going to lack goofiness. If by some miracle a company has The Perfect Agile process, that in itself is goofy as gently caress and probably terrible in its own way.

That perfect Agile process is only perfect for a minute and then the requirements change

# ¿ Mar 10, 2016 18:58

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Jo posted:

a non-functional line that I had added

why

# ¿ Mar 11, 2016 20:31

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

piratepilates posted:

The 2016 Stack Overflow survey results were just published (somehow I always miss submitting data in the survey):

https://stackoverflow.com/research/developer-survey-2016

everyone who self-identified as rockstar or ninja should have to wear a "kick me" sign on their back for the rest of their natural lives

# ¿ Mar 17, 2016 15:59

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

It sounds to me like your W-2 position has turned into a 1099 instead, with increased tax liability for you. Was it W-2 or 1099 before?

# ¿ Mar 25, 2016 01:18

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

ChickenWing posted:

Consultant job just called and we're setting up a meeting with some of the people I'd potentially be working with.

come on

The person who called asked me for my salary and I said I'd prefer not to disclose right now. This is the correct answer, y/n? Everything I've heard makes it sound like I shouldn't ever let them know what I'm currently making so I don't get lowballed on a salary, but the caller made it sound like it was required information.

They always will, to try and pry it out of you. My stock answer is usually something like "I'd prefer any compensation discussions be based on the value I can bring to your company, not some other company."

# ¿ Mar 30, 2016 17:51

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

KoRMaK posted:

I read somewhere, some time again, that sprint points shouldn't be used as a measure of productivity. I also read that they probably shouldn't be used to determine promotions on.

Is that true? Why is it true? I'm trying to build a good case against using them for promotions. I could be wrong though.

Incentives for individual productivity instead of team productivity end up penalizing people who go out of their way to help others, and create environments of competition instead of collaboration. Those people who facilitate communication, information flow and cross-training across the team end up moseying on over to another company where they're not perennially taken advantage of by their peers and clueless management.

# ¿ Apr 13, 2016 02:30

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Infinotize posted:

A consultant gives an org with no leadership (like mine) or terrible infighting an external thing to point to and say let's all just turn off our brains and do what the "expert" says.

Why don't you hire another consultant to address the infighting?

# ¿ Apr 14, 2016 15:32

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

smackfu posted:

Remote pair programming: always terrible or can it be tolerable?

I solved a major production issue in our code over the phone the other day. It all comes down to how you all work together. Determining that fit can be tough if there's no pairing component to hiring in the first place, though.

# ¿ Apr 16, 2016 00:12

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Skandranon posted:

So 4 necessarily goes to 5 to reflect this uncertainty

Pedantry: 4 isn't a Fibonacci number

# ¿ Apr 18, 2016 18:58

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Rocko Bonaparte posted:

Okay I'm not too surprised by the answers. I think I have a better question anyways. Once the smoke clears on planning and you have closed the story, how much time do your smallest stories tend to take, and how much time do your largest stories tend to take? I'm curious if there's a common granularity here. Note that I am saying nothing about points here, but I suppose I will just show my hand for full disclosure. I'm thinking too that 1 point roughly corresponding to a week is way to coarse. You can argue it doesn't matter, but I'm not allowed to do 0.5, and zero is troublesome for calculations. I'm suspecting that a lot of people wind up with the smallest user stories being about a man-day of work. That's not even necessarily a full 8 hours.

There's no such thing as an 8-hour person-day of development work unless your team members don't talk to each other or their management, don't have meetings, don't do code review, don't meet or talk with users, don't work with vendors, don't respond to emails, don't support production issues, and don't context-switch. Get this dumb fallacy out of your organization immediately, because it's one of the easiest to disprove.

# ¿ Apr 18, 2016 19:10

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Cicero posted:

But why does it sound half as complicated? Because to me, when I think something sounds half as complicated, that's because it feels like it'll take half as long. I guess to me "complexity of a task" and "how long it will take" are effectively the same thing.

Tossing around terms that we've probably all heard before from Brooks way back in the '80s, software has two kinds of complexity: inherent complexity and accidental complexity. We're pretty good at measuring the inherent complexity of things, but as software systems grow, so does the amount of accidental complexity. Features don't exist in isolation; they need to be integrated somewhere, which usually necessitates some kind of refactor or new abstraction in some unrelated part of the system. These cascade down the line. As the software system gets bigger and more complex, the time taken to add any particular feature will invariably get longer. One thing that story points accomplishes is decoupling the time estimate from a story at the beginning of a project from a similar story at the end of the project. If your velocity is falling even though your assessed complexity is staying the same, it shows whoever cares about these metrics that accidental complexity/technical debt in the system is beginning to hamper the team's throughput at delivering features, and time should be reallocated for refactoring or culling things that don't matter anymore.

# ¿ Apr 18, 2016 23:05

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

HFX posted:

The problem is, that no one outside of a dev team ever wants to operate that way. They want everything done in number of hours with firm deadlines 3 months in advance.

There's no benefit to shoehorning a couple of Agile buzzwords into a waterfall development process to pull the wool over the dev team's eyes. If the business is going to insist on waterfall, they're going to get waterfall.

# ¿ Apr 18, 2016 23:15

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

smackfu posted:

I mean, the whole point is that if you add a specific amount of points to the two week sprint, you can evaluate how you did at the end. Didn't finish all those stories? Then do less points in the next sprint. Finished early? Add more points to the next sprint. It's pretty natural in its adjustment.

Yes, you can do the same exercise with hours, but once you start saying you can do 70 hours of work in 80 hours, you might as well call those 70 hours 70 points.

JawnV6 started to get to this, and it's something that's obvious but needs to be explicitly stated: it's equally important to actually review problematic estimates in your retrospectives. Was something much easier than you expected because some of the plumbing was done for some unrelated story some number of weeks ago? Was it much harder because the interaction flow for this feature was incompatible with the flow through the rest of the product and substantial portions had to be completely redesigned? These are qualitative lessons that the team should be learning, that should be part of the oral history of your team. Like Lean, Agile is beyond useless if you're not constantly learning. Moving the goalposts to make yourselves feel better about your estimates isn't learning.

# ¿ Apr 18, 2016 23:39

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Jo posted:

I very much agree that it's important to look back at estimates, but I also have to wonder if the variability in performance for single developers is high. I'd imagine the natural variance in a single person's performance contributes about as much as a bad estimate.

Beyond real suspected competency problems, my take is that looking at velocity for an individual developer is a counterproductive disincentive. But you're of course right that people's individual productivity will wax and wane based on what's going in their lives, phases of the moon, butterflies in China, etc. Competent leaders should be clued into these things, but making predictions based on any human-based model is really, really hard. My general take is that small variations aren't worth obsessing over until they become data points along a trendline.

# ¿ Apr 19, 2016 01:42

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Daily standups aren't for bringing up issues, unless by "bringing up issues" you really specifically mean "I was bitten by this behavior yesterday in this thing we have/use, hey everyone, watch out for this so you don't get bitten too."

Facilitating communication really isn't that hard.

# ¿ May 12, 2016 19:52

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

amotea posted:

I agree, our team is distributed and we just use Jira and Slack to keep track of who's doing what.

The problem with using Slack for anything important is that chat is even easier than email to declare bankruptcy on.

# ¿ May 12, 2016 19:54

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

revmoo posted:

I'm glad I work in an environment where we don't need to "facilitate communication".

Out of curiosity, how frequent are your releases?

# ¿ May 12, 2016 23:40

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

necrobobsledder posted:

I had never heard of anything like this form of plausible deniability approach to compliance at a Fortune 10

I can tell you that when I worked at Time Warner, they retained emails for exactly 30 days.

# ¿ May 15, 2016 04:32

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

The amount of risk management on a project should roughly correlate to the amount of value at risk for that particular project.

# ¿ May 26, 2016 19:36

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Gounads posted:

I find it usually correlates more cloely to levels of bureaucracy in a company

Sadly true. Bikesheds for everyone, you just need to agree on what color!

# ¿ May 26, 2016 20:19

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Gounads posted:

I once worked for a company that had a two level change-review board plus a release-board.

Did they make missile software? Medical software? No. They made educational software for kids.

This was me, except it concerned photos of Kate Middleton's wedding and stories about what Kim Kardashian was wearing. I re-engineered our infrastructure release processes specifically to end-run around the CAB without them being entirely aware of it.

# ¿ May 26, 2016 21:38

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Khisanth Magus posted:

I think it really just came down to her being one of the most senior members of the team resulting in her updates of "still working on x project" to just be accepted at face value. These really had no milestones beyond "competed on this date" and our "scrum" meetings are completely devoid of the kind of details i expect out of them based on previous experience.

I think really the base problem is that this company is growing very fast, its IT projects are likewise growing, and the project management and procedures just haven't been able to keep up.

I can't even blame this person for not wanting to do any work. I get that the company is growing, yeah, but this is irresponsible Mickey Mouse poo poo to the most extreme degree. A single person is in charge of outsized deliverables instead of small stories, no code review is happening, the client isn't engaged in any of the changes that are happening (read: you are doing waterfall), and management is absolutely clueless about what their critical projects look like for months? The whole company deserves to burn down over a red stapler.

# ¿ May 28, 2016 19:38

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Khisanth Magus posted:

In related news, we have since discovered that the requirements we were given for the absolutely critical project were completely wrong, requiring a rewrite of most of the work we have done over the past few days.

"discovered"

e: sorry for excessive schadenfreude

Vulture Culture fucked around with this message at 22:32 on Jun 1, 2016

# ¿ Jun 1, 2016 22:25

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Steve French posted:

On the other end of the spectrum, I've seen some pretty terrifying things that resulted from developers using ORMs to indirectly define or modify schemas without someone around to nanny them.

This is why not doing code review makes baby Jesus cry.

# ¿ Jun 2, 2016 16:03

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Steve French posted:

You're making an assumption that there was no code review, rather than several people being oblivious to the underlying implications of their ORM usage.

I was responding specifically to the "without someone around to nanny them" part, which is something to which code review is exceptionally well-suited. But if your entire development team has no idea what they're doing, you need to do something else I guess?

# ¿ Jun 2, 2016 18:43

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Dirty Frank posted:

Code review at my place has almost no common characteristic with meetings. There's no group discussing things, its one senior developer (which ever one got assigned to that changeset*) handing down judgment on a changeset. Whats it like everywhere else?

*Sorry for the TFS centric vocab

We assign code reviews to the people most familiar with the components being touched so they can tell the authors if they're doing anything really dumb. Senior/junior/whatever really doesn't factor in.

# ¿ Jun 2, 2016 23:58

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Volmarias posted:

That's what design documents are for. You should design the thing ahead of time, instead of doing it and saying "ok this is how it's going to work, hope no one is confused or disappointed."

If it's that complicated, just put the design doc through code review like everything else

# ¿ Jun 3, 2016 18:26

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

necrobobsledder posted:

Agile is oftentimes misused when you're really looking for "lean" principles that are even broader and apply across more than just software (I've never heard of Agile being used anywhere other than software dev, and it was a Bad Idea when I led an ops team for sure because we couldn't commit to anything ever). That is, lean is to do the minimum you need to get to a reasonable set of expected results as you go along because your project could just get cancelled for random reasons anyway so long-term planning has only so much benefit and is only of value when you have sufficient stability (and really, inertia) to consider sunk cost problems and strategy.

I think the Bad Idea part is changing, but it took ten years of tooling developments from the Cfengine days through Docker for me to finally be able to run ops competently across an Agile product.

# ¿ Jun 5, 2016 19:27

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

necrobobsledder posted:

For me ops means "traditional ops" since the whole "devops" term is popular and has a very different workflow and set of connotations and where the term "configuration management" evokes vendors, not technology like cfEngine, fai, Puppet, Chef, Docker, etc. That is, ops means you're thrown a bunch of software products over a wall from vendors typically outside the company and you act as computer janitors with minimal feedback to the products you're stuck supporting and keeping up a bunch of black or gray boxes with a pretty inflexible n tier architecture almost always (I've never been in a place where they treated a Cassandra or Hadoop cluster the same way they treat an SAP, Oracle, or Exchange cluster under the yoke of ITIL processes, for example). Almost no traditional operations person I've worked with has worked with Agile intimately before I showed up and started doing things "like those software people do." Ops for a software company's SaaS product, for example, is much easier to sync together with any operations team because schedule sync is much easier than with an n-vendor, m-project ADHD approach to tasking for operations people.

That aside, the whole reason DevOps exists is because there was a massive impedance mismatch between Agile-style development and waterfall-style operations. It's okay to try to move the needle in an organization that's weighted to death with its own inertia, but swinging the impedance mismatch the other direction when you're working with waterfall software is equally counterproductive as a general approach. There's no good reason to run your BI suite on Kubernetes.

# ¿ Jun 5, 2016 23:22

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

necrobobsledder posted:

I haven't seen operations go through any sort of project management paradigm that could even be described as waterfall due to operations people oftentimes serving as L2/L3 helpdesk that organizations usually have a separate team that handles projects while another team handles day-to-day interruptions and toil (this is usually the team that gets outsourced I've found because they can't retain decent people to toil and the work requires far less talent to successfully accomplish). We both know that this is probably a Bad Idea as well because it won't scale, but I don't think most of the Fortune 100 knows anything about effectively scaling teams and software with infrastructure in the first place.

I disagree, I think this is the hallmark of waterfall-oriented IT: literally the entire organizational structure around an internal product is structured against what will present the least risk to the milestones defined on the schedule (i.e. what will make the project manager look good).

Vulture Culture fucked around with this message at 17:42 on Jun 6, 2016

# ¿ Jun 6, 2016 17:39

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

In the context of poo poo redirection, a good manager should also treat their employees like grown-ups. I've seen managers err too much on the side of poo poo umbrella. The right balance is for a manager to insulate their people from the pressures of the political voices, but the team should still be informed of what those political pressures on the team actually are, because it turns out grown-ups make better decisions and do better work when they know who it's for and why. It also helps them understand what their manager is doing all day, and I find things just run smoother when empathy flows correctly in all directions.

# ¿ Jun 23, 2016 03:32

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Yeah, there's a bunch of people who have no idea how to manage memory, but there's a pile of embedded systems programmers out there who have no idea how to manage client render performance too.

# ¿ Jun 30, 2016 02:42

Adbot: ADBOT LOVES YOU

# ¿ May 2, 2024 06:12

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Cuntpunch posted:

I'm personally a big fan of folks who debug by sticking a stdout-or-equivalent after every single line of code.

don't knock trace logging, especially for distributed systems

# ¿ Jun 30, 2016 17:06

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Working in Development: Leaving sounds like a great decision.

«‹›12 »