Programming as a career

programming means writing code that anyone can understand and maintain.

fixed

One place I worked at, someone made this independent decision to learn Groovy by building one of our systems in it. It was all I heard about for years after he left.

it took me almost a year to find a job with 10+ years experience this go-round; i should write a book about all the dumb early-stage NYC startups vett3ry and their ilk kept sending me to (crypto for the publishing industry! uber for ambulances!)

i've been at this new (permanent) gig for like three weeks now and i'm finally starting to settle in a little; i've probably pigeonholed myself as a digital agency guy forever, but i really like this one. unlike other senior/lead/etc titles i've had in the past, this one isn't bullshitting me; i have actual responsibility. my current client is hell-bent on using wordpress as a headless cms to serve graphql to react, which i am...less excited about.

your client is high as a goddamn kite

PY wants to merge 4 commits into master from multi-s3

+427 lines -105 lines

zero comments on what the changes do

(same person added java 11 to the CI workflow the day after it was released)

Any tests, or is that a silly question?

Just a test of patience, it sounds like

there are unit tests but they don't explain what they are doing either.

public void itReturnsAnS3ClientByGettingAnSTSCredentialProviderUsingTheBucketToRoleArnMapping() throws Exception

(that's one of the unit tests)

That test name /sounds/ descriptive to me, but I don't know enough about the Amazon cloud to know what it means, so ... i assume ARN is a thing that makes sense in your domain :o

We added a commit-hook some years ago that rejected every commit that had less than N characters in the commit message.
It helped, though we still get people who will just do like 10 commits in a row that's just the same jira issue number over and over, with no explanation of what the various changes actually are.

I might actually BE that guy though. I made a small commit yesterday where my message was something vague like "optimized and made easier to read". Immediately got a message from someone telling me he couldn't read the code anymore. D'oh.

I should probably take this to the 77 thread, but the branch a colleague has merged in has four commits, all saying 'initial changes'

The aforementioned no comments / Java 11 guy is my new team lead. He is half my age.

we just went to 8 a few months ago. very cool but we're pretty much left to Google everything.

Literally half my age. I was programming, professionally, before he was born.

Ugh, sorry.

oof... trying to find some black humor - failing.

Turned 30 a couple months ago and I hope to be in a non-programming role by 31

Personally, I'm >40 and honestly the best stuff I've worked in has been in the last 10 years.

But there's lots of places where what's important to the craft isn't defended, and I sometimes leave quickly when that happens.

I've come to appreciate the style guides, reviews and processes of my megacorp because they prevent a good fraction of this kind of shit. Just read about something on hackernews and want to check it in? Sorry, let's slow that shit down because everyone has to buy in first. Want to make a big change? Yes you can. but you have to be able to explain and defend it.

On Thursday we discovered that a big part of the project that we've been doing for the last 8 months just wasn't implemented. It had been overlooked.

On Friday we discovered that another big part of the project that we've been doing for the last 8 months just wasn't implemented.

Neither were in code I wrote, but both were in components that I reviewed and missed. Both were things that were meant to be configurable but weren't. I've never liked the way things are specced out here, not enough detail, and in both cases the things were new requirements in tickets where the ticket titles suggested there were no new requirements, just reimplementations of existing functionality. But two balls have been dropped and I feel slightly responsible.

Yeah, badly written stories is something we try to identify quickly. Is there a scrum master that can help out? Not drinking the Agile Kool Aid, but I’ve found that good SMs, which are kind of hard to find, are helpful.

not sure we have a 'scrum master' as such. we don't really subscribe to the agile thing fully.

we've had problems with tickets before - there was one set of BDD scenarios attached to one piece that i implemented only to later be told that it belonged to something further down the workflow. (we were redoing the entire workflow, i didn't know enough about it, figured it was being moved as part of the rewrite, i lost 3 weeks doing that, argued with the writer who insisted he was right)

the new bit isn't that onerous - we currently have a bunch of things

A1
A2
A3
B1
B2
B3
C1
C2
C3

where all the As are grouped as a kind by the configuration and currently ignored, and then all the remaining 1, 2, 3s are processed appropriately. but now they want A3 to be treated specially. we could do that in code but, like the other new piece, they want it in config to make it easier for OPS to support and the current structures can't differentiate between the cases.

it needs a rules engine really. but everybody i know that has used one has had a terrible time of it. and i just can't trust something called "Drools".

My workplace just appointed me scrum master for life. Apparently all this means is you have to hold 15-minute long meetings every morning where everyone talks about what they’re going to work on during the day. All I have to do is facilitate the meeting and make sure we all stay on task. That can’t be too hard, can it?

I'm all in favour of agile methodology but the terminology for some reason makes me physically sick. Kanban, burndown charts, and worst of all scrum master (apologies Mr Snrub).

Jesus christ I am not in favour of this shit: https://www.agilealliance.org/glossary/nikoniko/

I'm starting to get brought into those meetings as a "specialist" and it kinda feels like I just joined a cult

i was gonna say - "ceremonies" is even worse jargon than the ones cited above. every single 'retrospective' in my team becomes someone questioning the merits and demerits of scrum v kanban or vice versa. there are some major zealots for agile and within that there is zealotry for methodologies and ways of working. equally, it's so nebulously defined that if somebody doesn't like a suggestion or a comment about how the team works, they might say 'that's not very agile' as if we are all being watched by the agile god who will smite us for offending him, even though someone else's creed would insist that 'yes, in fact defining roles and responsibilities is a good thing to do for any agile team"

i didn't work in software development before agile and i can imagine it is largely a force for good, but it is tiresome too.

i am in hardware, and we are doing this now

another classic is people hiding behind agile to avoid doing things. like i have a delivery manager currently and he's like 'the way we work in agile, it's we as a team who decide how we will organise our work' and this is sort of his excuse for not even gathering info, collating the team's views, or trying to inform discussions in the team to a point that such a collaborative approach might be even vaguely useful or feasible.

it often ends up reminding me of that simpsons with the 'i DO... what i FEEL like' guru - i've worked in other places where it 'wasn't agile' to be unhappy that a colleague took a month off at short notice in a majorly busy time, or like it's 'not agile' to express a negative opinion, etc etc etc.

xpost

xp

my experience of agile has largely been that it's a way for management to abdicate any responsibility whatsoever for running a project, because deciding on requirements or planning anything is not agile. just give a vague idea to development and tell them to get on with it, then complain when what frustrated developers come up with isn't what they imagined in their heads

my current manager doesn't bother with retrospectives "because people complain about things but nothing ever changes" which at least is "refreshingly honest"?

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?