fantastic in plastic posted:

I think there's good points to most of those things, at least in the abstract.

Asking one question at a time is a good idea in general, because otherwise you risk overwhelming the other person.

rt4 posted:

I don't really think codes of conduct are a good way to handle it (I prefer unapologetic surprise bans) but you've got to set a standard of behavior somehow or you end up with Twitter.

Shirec posted:

Speaking of Git, my team (almost entirely my boss) let branches get entirely out of hand, with what we were creating branches from, what production was, how old master is, and how insanely many branches we have (I think around 30?)

Now my boss is freaking out because a unit test is failing sporadically and is making us re-build all the work we did last week so we can get a clean sprint branch for master. We already knew some of the unit tests were borked and needed to be re-done, but lord.

He’s acting like he didn’t know any of this was happening either, he constantly says (when things go wrong) that he can’t be that down in the details and doesn’t know it if we don’t bring it up

edit: make that 50-60 branches

Shirec posted:

Again, I might be being unfair

strange posted:

"Why is it mandated to such a high%?" as a genuine question. Most projects I've joined struggle to get anywhere near that.

Boiled Water posted:

Bongo Bill posted:

The investors want someone who will lie to them - and I stress that any attempt to forecast the timeline of an immature project farther than a few weeks is a lie - and you are going to set yourself up for abuse if you agree to become that person.

Murrah posted:

The app is a PHP Symfony app

Murrah posted:

There are no automated tests or anything like that

Murrah posted:

and I just instinctively felt like I was at risk of introducing several bugs for every change I was making

Murrah posted:

Im just left with the sinking feeling that there will certainly be more bugs and some that won't get discovered until production.

Ape Fist posted:

If you're working with Ligatures turned on, are you even a real developer?

Ape Fist posted:

You are a hiring manager whose also a dev. You can hire one of these people:

Person 1: Has a strong grasp of theory, understands software design concepts quickly, but spends an above average amount of time on stack because they tend to forget syntax things. As a result their code is sometimes untidy, an not ideally optimized.

Person 2: Is extremely good at syntactical recollection, writes clean and efficient code which compiles nicely most times through repetition, but absolutely can't grasp design structures or really any of the theory outside the 'local scope' of what he's working on.

Pedestrian Xing posted:

I've written for platforms that don't support any sort of testing and it's horrible. I'm very pro testing, I just don't like writing pointless ones to get coverage back to X% because another dev wrote a 400 line function with no coverage for the third time this sprint.

Protocol7 posted:

Unless you work at my company where it can take weeks to hire a candidate (and the candidates usually find another position while they wait), so they don't fire any of the programmers they do have, even if they are grossly incompetent.

I have never seen such poorly formatted and clearly copy-pasted from StackOverflow style code in a production application until I worked with some of the developers on my scrum team. But beyond raising my concerns in a code review and talking to my manager about it, I can't really do anything else.

Until an eventual bug is filed in the code and I get to refactor it, of course.

In good news they gave me two 10+ percent raises this year, which makes it a lot easier to deal with the BS, since now I can afford more whiskey.

Faith For Two posted:

He also doesn't like how any of the C++ testing frameworks work so I'm rolling my own. I thought google test would meet all our requirements but he doesn't like working with xml our json output.

Kevin Mitnick P.E. posted:

Things that matter, in order:

1. Documentation
   
2. Functionality
   
3. Consistency
   
4. Correctness
   

Things that don't matter:

• URL structure
  
• Signalling errors in the status code or response body
  
• Content type
  
• HTTP verbs lining up with semantics
  

Assuming the documentation is up to snuff, this is a good API.

Protocol7 posted:

I got a recruiter email with the subject "Alexa, find me a Jedi Master level software engineer".

I typically just ignore recruiters, but in this case I was almost going to reply and tell them to gently caress off with that cringy bullshit. It turns out, though, that it was from an actual Amazon recruiter looking for people to work on Alexa, so it kind of makes sense. I kind of laughed after I realized that.

Subjunctive posted:

Wait, pagerank was ML? What decision changed over time? I haven’t read the paper in a while (and AIUI Google’s ranking has never actually been what’s in the paper), but I recall it being a deterministic algorithm independent of previous inputs.

Volmarias posted:

If you don't have a code review system in TYOOL 2019 you need to find a different employer

Pollyanna posted:

Thankfully I’m not really the one that has to deal with that mess. I’m just taking over during the holiday week. But if they want to put me in that position permanently...hell naw.

Pedestrian Xing posted:

The pre-commit checker doesn't stop this but it does stop me from pushing anyone else's commits so I can't even restore all the missing work. This is a recurring issue with a few developers. Nothing like coming in in the morning and seeing a week's worth of work gone.

necrobobsledder posted:

I’ve accidentally force pushed to a shared branch because I was in the “can force push to master” users. Thankfully I didn’t regularly gc and was able to recover from the reflog but our Jenkins jobs went nuts for a while and I had to clean up our environments as code from a month ago was pushed to our dev and staging environments. This is why production pushes should always be tag-based rather than HEAD based at smaller scale of teams where ACLs can be pretty loose.

vonnegutt posted:

I try to do this as well, and I find it works best when the work is well-defined and straightforward. Other times, it starts well and then turns into 'wip refactoring' ... 'wip undoing refactoring' ... 'wip try again' ... 'wip ugh' and then several 'fix tests' or 'tidy' commits at the end. I find this is especially the case when doing things like upgrading frameworks or deployments. Not every task can be broken into a orderly progression of commits. Further complicating matters, in order to work out things like CI pipelines, sometimes you need to commit just to trigger some post-commit action.

Still, I totally agree that doing one giant commit for each PR is a nightmare.