Programming as a career

i think our retros are useless for that reason, but it points to a problem of culture when they never result in change.

i think a huge problem with agile is the delivery manager (or scrum master) ends up as some middle management type who thinks their job is to maintain discipline and do the odd job interviews when in fact for it to work well it's more of a servant leader role. i had a delivery manager who like cleaned the desks every morning and evening. when i first started i thought it was absurd and then over time i realised that he would do literally every possible thing to make your work and the delivery of the team's work go more smoothly, he would meet anyone on your behalf, he would help you in any way he could. like your parents when you're a kid or something, i prob didn't appreciate that enough at the time!

admittedly when I had my performance review recently I said to her "I don't know why we persist with this ridiculous charade" so I guess I'm in the same position

lol - they really highlight it though - same problems every week and nobody doing anything.

we have not as yet managed to seamlessly integrate agile into our lean prince2 philosophy but otoh our servicedesk is itil'd to an inch of its life

turns out the bulk of the unimplementated functionality was in the Epic ticket (and not expanded beyond note form), and didn't make it to the Story tickets we were assigned and were working from...

most people are terrible at writing (tickets)

Yeah, that's why when I brought it up I didn't mean for it to be a be all and end all. I can go on for days about the problems agile has. My experience has been mixed.

In hindsight, I agree with Fernando that a scrum master is supposed to help things run smoothly. The best scrum master I ever had so far was this way. And I grew to deeply appreciate her work.

Having said that, agile is rarely fully implemented in most organizations I've heard of, which is what makes it such a difficult thing to pin down and criticize. Theoretically, yes, it should work, but in practice it's always this weird subpar version of agile that is used.

Anyway, koogs, glad that some(?) of it was figured out. Hope things improve!

my worst "agile" experience involved daily stand ups with 50 people in. about as agile as a concrete elephant.

We are up to 15 or so if everybody's in. Worst part is that it's a long, narrow space so you can't hear people standing on the far side. And one of them has a habit of standing directly in front of me.

There's definitely been some lack of reading of requirements, that thing where you're so certain of what you're doing that you don't check, but I don't think we're entirely to blame. Deploying to live tomorrow regardless.

(If we had done the missing bits we wouldn't be done yet, so...)

wait do ye actually get requirements

Having said that, agile is rarely fully implemented in most organizations I've heard of, which is what makes it such a difficult thing to pin down and criticize. Theoretically, yes, it should work, but in practice it's always this weird subpar version of agile that is used.

yeah i think that prob is true of almost all my four/five years experience with it - it prob sounds almost cliched but imo the organisation has to be trying to develop a culture of agile top to bottom for it to really work. that's the diff between standups where nobody bothers to try to run them effectively and yeah, it's 50 people and taking 70 minutes, versus actually seeing how short the standup can be. i actually think standups are a p good example of the cultural stuff - one place i worked anyone who went off topic or too in-depth would instantly be told this, but because it was something we did in the team, and because the place was a really nice place to work, and because we all socialised with each other, and because we had good retros etc etc etc, it never felt rude or snippy, it just was a culture where productivity and questioning things was encouraged in a democratic way.

in other places the same dude drones on in a standup trying to aggrandise his own importance/authority, tho eventually someone will fix it. i guess it's all connected tho. constant shit tickets/badly scoped work leads to longer standups, retros clogged with issues of scoping etc. the delivery manager or scrum master (i've seen the same role called either but ymmv) really is the key.

tbh when I eventually crack up and rage quit my job I may have "must not be an agile environment" for my job requirements, I've been suffering the scourge of agile for 10 years now and enough's enough

Are there any decent size development teams/companies that are not agile?

Working at a startup is such a gamble.

everybody says they are agile, no matter what their process or lack thereof is

This is all very useful. Thanks everyone!

has it gotten to the point where college students interested in software engineering are warned that this kind of thing is actually going to be a major part of their day-to-day, or even forced to take courses on it?

because those poor saps who are just into coding and wanna code for a living, lol

I'm in favor of any process which prevents code from getting written

I was told from my first CS course that all the coding is done by subsubcontractors in India

In my experience, coding is probably only 40-60% of your day to day anyway. Unless you’re on a refactoring spree, I guess. But so much time is already wasted in meetings planning, strategizing, designing, redesigning and generally trying to communicate

Communication is such a huge part of the job and a skill that hardly anyone tells you going into this line of work that you really need to work on, I think.

my job is p much to do the communicating on behalf of our programmers but i also get the coffees

You want to move to the states, darragh?

cant afford to, the pension here is just unfuckwithable

The rise of DevOps is insidious too. I can spend whole days doing cloudformation templates or worrying about cnames. That's no fun.

has it gotten to the point where college students interested in software engineering are warned that this kind of thing is actually going to be a major part of their day-to-day, or even forced to take courses on it?

because those poor saps who are just into coding and wanna code for a living, lol

― j., Monday, 8 April 2019 13:59 (eight hours ago) Bookmark Flag Post Permalink

I was told from my first CS course that all the coding is done by subsubcontractors in India

― brimstead,

I keep reading this, but 80% of my job is writing code for new features, 10-15% fixing bugs or fishing information out, and 5% any of this other stuff. standup is done in slack

Do you mean devops as a job function or title? I barely have to deal with that because we have a dedicated devops, and any other infrastructure stuff that touches code gets handled by our lead developers.

I'm getting more responsibilities at my current place, meaning more meetings, and I've gotten a reputation as the unit tests guy, so now I get more pull requests too. I'd say writing code, either for new features or tech sent, is 60-70% for me right now.

devops, the way it used to be two jobs, both with largely different skill sets but is now one. i'm now supposed to be an expert on, i don't know, machine cofiguration and dns, rather than just software, stuff that people have years of training in but which i just google.

i get the nasty feeling that new team lead has just assigned himself the bits of software that haven't been written yet and is going to do them himself. which strikes me as... indelicate?

^ he did. Changed about a dozen files that we were working on yesterday, introduced new idioms into the code, used an editor that changed the whitespace on empty lines so that the diff was twice as large as it needed to be and then got another member of the team to review it. Didn't involve us at all. Just rude and it has fucking annoyed me.

I'm in a team that's basically enterprise services for our department -- providing things like queuing, workflow, etc. engines and pushing things like data governance so everyone can write code that uses the same concepts across development groups

learned last week at a conference that agile processes fucking up groups like mine is nearly universal. coordinating with other teams, even when multiple groups are working in the same realm, is something agile development groups refuse to do. so while it's kept project scope reasonable and kept groups on-task, it's a complete nightmare from a data analysis and reporting standpoint if anything works across multiple development teams

we're going to end up taking the carrot/stick approach: if you want to use the larger scale tools that make your development cycle easier, you're going to have to coordinate with the data governance committee

Trying to keep track of all these different approaches and philosophies to software development/design is overwhelming. You’d think this would be the kind of thing we’d have learned about in CS school but no, we learned about AND, OR, and NOT gates.

trouble is nobody actually knows how to develop software so it's impossible to teach

otoh my work sends me on all these courses

i cant program for shit obv

learned last week at a conference that agile processes fucking up groups like mine is nearly universal. coordinating with other teams, even when multiple groups are working in the same realm, is something agile development groups refuse to do. so while it's kept project scope reasonable and kept groups on-task, it's a complete nightmare from a data analysis and reporting standpoint if anything works across multiple development teams

i've never seen collaboration team to team across a big overarching project work well, dunno if it's even possible. i'm more on the design/user experience side, mainly writing content based on research and working closely with interaction designers, and while there are reusable things and some general stuff that can be shared, i've also seen the pressure to treat the work like a patchwork quilt can end up totally ignoring the needs of users. i've learned to an extent, unless something is completely absurd, that if something appears odd or illogical to me in a project i didn't work on, there's a good chance it's fixing something that came up in user research that i didn't see. i mean, unless every element seems odd, then it might be just crap.

it could be i've never seen this collaboration work well because again, the people doing it are middle managers doing roles that require knowledge they don't have.

i mean i know in theory you have some flat structure with everyone dovetailing perfectly but i've also never seen that, seems to me you need some people who are good at facilitating collaboration and whose job it is to join the dots between things. but it always seems intensely difficult and complicated. planning one project is hard enough without another 20.

among the reasons why software should be developed by teams of two or three programmers and a manager embedded with every non-software organization doing almost anything instead of in huge software companies

trouble is nobody actually knows how to develop software so it's impossible to teach

― moose; squirrel (silby)

trouble is nobody actually knows how to make software engineers rigorously follow the standards so it's impossible to implement anything elegantly.

if software developers were rigorous thinkers they'd be real engineers, for like bridges or something

Hey now! [insert gif of the Tacoma Narrows bridge here]

Seem to recall something on Coding Horror once about how the majority of people who code never really get any better at it.

https://blog.codinghorror.com/how-to-become-a-better-programmer-by-not-programming/

the software architecture conference I went to a few years back was enlightening!

at that level, it's all larger patterns, largely platform and implementation technology agnostic. that's obviously an approach that's hard to stick to when your in-house people immediately jump to the same bucket of tools, but there is the possibility of a pure vision

re: Fernando's comment about a big overarching project, our problem is that the entire business, which is a research-to-commercial pipeline, is in effect *one project*. so in order to gather metrics on the entire process, from the conceptual phase through the pipeline, you need a solid data model or there's no traceability. instead, we get a series of task systems that are single-purpose with minimal handoff between them

if yall think agile is bad, pray you never have to work at a place that implements SAFe

Moysey certainly couldn't manage it

Underlying principles of SAFe

1 Take an economic view
2 Apply systems thinking

We had some SAFe ideology at a previous employer. The concept as a whole could never fly because developers still had a strong say in how to manage projects.

Hey, do this thing, it's quite urgent.

Ok, here you go.

Thanks, here are 6 pedantic review comments to slow you down...

Gah!

String processRequest() {
  // do something here
  // and here
  String messageId = sendReply();
  return messageId;
}

void someMethod(String input) {
  if (input != null) {
    // code that does something with input
  }
}

(
the crime in the first one is that i could just return the result from sendReply, i don't need the local variable. the local variable makes it clear what the return value is and allows you to attach a debugger to something should you need to debug it.

the crime in the second one is that input cannot be null because the calling method has already checked it. i see no harm in checking it again just in case. also, you can't guarantee that future methods won't call this method with a null
)

i hate the nitpicking that is rife in programming. is it a male thing, i wonder. men will argue over anything.

I'm with you on point 2. what if someone else changes the calling method so it no longer checks for null?

Never submit anything 'perfect', always leave a little low hanging fruit. Though goes more for QA than PR!

code looks fine on both of those, people need to stop nitpicking

if it’s some public library that’s on github or w/e maybe standardize the style a little but, on the other hand, Microsoft’s samples for their Azure services that they publish on github is much worse

*are much worse