Programming as a career

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

I wish those were the types of issues that came up in code here!

that's my point - they aren't issues 8) why flag them and delay the fix that they wanted in the first place?

meanwhile, the new team lead, see above, is stinking the code up with cryptic syntax and bad config file formats but has such a superiority complex that he won't listen.

yeah I don't mind either of those. we deal with a lot of 3rd party software that uses our stuff so the more null checks the better.

also like it when code is easy to debug. I always get irritated when people write one line methods that invoke five separate calls, which can be really irritating to debug when something goes wrong. though Java 8 streaming and lambdas sorta encourage you to write this way, I've (luckily) never actually had a problem with those...they're like the one thing that actually work exactly how you want them to

the impossible bargain of using higher-level APIs that just work 90% of the time versus the struggle to wean people off them when you've outgrown that use case

My life has become easier due to recent versions of Eclipse (the Java IDE we use) having a debug variable for "that function we just came out of returned this!"

I would have probably asked you to put in a null check if your method didn't have one. As much as possible you should never assume that any checks are going to be made before a function is called. This is basic stuff I would think.

First one is definitely a pointless nitpick.

had a fun time refactoring something yesterday...we call a module which returns a bunch of class codes, which has four components...two numeric codes, a description, and an indicator. for whatever reason the programmer decided to return this as an UnmodifiableVector of String[], which you have to read vertically (vec.get(0)[index] + vec.get(1)[index] etc) to return a full result...which I guess worked fine until we had to filter some out. I don't understand why people don't just create objects for stuff like this. Creating objects makes your code so much more readable and it is also fun and rewarding

I definitely agree that anyone nitpicking over this code has too much time on their hands. For the second, my personal preference would be to reverse the logic of the null check- ie if it’s null, throw- to reduce nesting, but I wouldn’t ever ask anyone to change it.

I've really started to like the defensive coding strategy where the entire first section is null checking, validation, etc. and then the rest is just "do stuff"

also lets you throw the right exceptions more easily

That vertical string array is one of the craziest things I've ever seen.

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

IME reviewers do this when they don't feel like they have any other substantive to add, whether it's a gendered thing idk!

True, I've done it myself, just to prove that I've read it in detail. But always try to phrase it as a comment rather than something that's wrong and must be changed

Certainly I don't keep insisting it's a problem after the writer has explained his reasoning, as happened here. (For example, I said that I used a local variable because it makes using the debugger easier and I was told that I should instead set a breakpoint in the calling function and use the special return value thing in the variables window. My way I get to *mouse over* the variable name *in the method i'm debugging*, no extra windows taking up screen space, nothing. Plus it explains what the return value is, whereas the method name isn't always obvious)

https://www.youtube.com/watch?v=AEBld6I_AKs&feature=youtu.be

https://www.youtube.com/watch?v=AEBld6I_AKs

xp An error occurred. Please try again later. (Playback ID: gmdBDNX-8DB0KXgZ) lol

Please open a ticket

If the ticket management software is anything like the one I use at work, I'll have to make a second ticket when the ticket management software crashes when I try to make the first ticket.

What hub are you on?

Please send a screenshot to the following distribution list: sixfootmeneh✧✧✧@vax✧✧✧.c✧✧

Would it be cromulent to ask an intern candidate to differentiate a function that I need for work because they list calculus as a concentration?

Is that something they'd probably need to do on the job?

they opened the door

Not normally! It's just that I'm working on a feature that requires equations that algebra can't solve, and I like human feedback to complement what Wolfram Alpha has given me.

I want, not I like.

Is SQL knowledge among developers something that's on its way out? And I don't mean DBA-level knowledge, just simple familiarity with basic selects, joins, etc.

It's all about the nosql now, I fear.

Probably, which is dumb, because databases are good, and it’s possible to use them in smart ways, but only if you know SQL, and nobody has designed a language other than SQL for RDBMSes that can actually use all their features efficiently as far as I know.

idk how common this is but where I work each team has its own database person. not that we really get any special privileges but we do get to optimize stupidly complex queries and run endless scans for marketing people

I certainly haven't used sql in 5 years.

Database layers in code always used to be a faff, as was waiting for the DBA to write you a stored procedure to do what you needed.

That said, getting errors at 9am every morning because you've gone over your opaque iops limit in an aws hosted dB somewhere gets old quickly too.

(first job I had involved the sql-based Informix report generator language and I used to love crafting those reports)