Imagine actually going to daily standup, wow
I made a daily meeting invite, and told my team to never show up to it. Lets them show up to work an hour later since I put it in the calendar for 930-10.
Post funny things about programming here! (Or just rant about your favourite programming language.)
Imagine actually going to daily standup, wow
I made a daily meeting invite, and told my team to never show up to it. Lets them show up to work an hour later since I put it in the calendar for 930-10.
That's why I only code as a hobby.
Less time is spent handling on-call issues if you do the code reviews, documentation, and testing...
Not necessarily. Also depends on competency of whoever is looking at using your software/investigating and the legacy of the things you described. A whole different scenario if it's because you forgot to write something in a ticket and someone coming to call for help with docker when you have a docker setup guide they never look at.
Ever received a Slack or a teams message that’s just your name but no context as to what’s actually needed? Like they need to confirm you’re there but don’t want to reveal why they’re asking.
“John.”
Problem is whether or not I’m present has a lot to do with the question.
Refer them to nohello.net
I am going to get a lot of use out of that URL.
I've been telling people they need to put a dollar in the jar when they do that, but I haven't actually been enforcing it.
"That's my name! You got it in one! Good job!"
Nohello.net or whatever the URL is
Thank you! I never knew about that site before.
Yes testing is such a big problem for those coders.
I mean, you're not hired to "code", you're hired to do software engineering. That usually means working with other people. Reviewing code is a win win situation because both get a second pair of eyes on their code and prevent each other from committing dumb shit that you might have to fix later.
I feel like these memes of hating everything other than lone coding is because you keep working for toxic companies. Ffs you're programmers, it's probably super easy to get another job. It doesn't have to be like this.
I feel like these memes of hating everything other than lone coding is because you keep working for toxic companies.
No, it's because we are working with humans and their deeply flawed organizations. As much as people hate corporations and love startups, both are always a mess. Every organization I've seen from the inside is barely functioning. Cruft, interpersonal conflicts, incompetence, or simply very bad market situations.
Software engineering kind of has to get involved with almost all of that. If you need to get approval from department A and Stacy just keeps changing what she wants, you'll have to carry that chaos into the development and it will usually percolate through half the engineering department, because hardly any interface is actually a stable attack surface. That means meetings, calls, meetings, reviews, meetings, and fucking Stephen again wants to pitch this weird framework he's so in love with, meetings, budget calls, because there's no way, simply changing the field length can take that much work, meetings, .....
It's not about corps vs startups. It's about having processes, good communication, dialogue, empathy. And it's also your manager's job to protect the team from externals that keep interrupting and making adhoc requests. If you don't feel safe in ignoring calls and replying with "I'm busy now, schedule smth today please", I consider that a highly toxic workplace.
Not to mention the fact that the more code there is, the more bugs you have.
I think QA engineering needs to become more widespread. The "extra pair of eyes" can't compare to a department of people dedicated to code review and testing.
You don't want a department that you throw it over the fence to, you want them embedded on your team. Keep those feedback loops TIGHT bois
QA and Code reviews do different jobs. Manual and automated testing will not notice your code is shit, so long as all test cases pass.
That's what QA engineering is for. They are integrated into the dev team and they pull double duty with QA and code review.
In my company QA is dedicated to manual and automated tests. I haven't met many QA engineers who could effectively review any of my code.
As a qa engineer this makes me feel better about myself. Because I'm included on reviews but never know what I'm looking at.
I've worked in places where QA we people with no coding knowledge who just clicked around looking for bugs, as well as places where QA never did that, only automated tests. And then there are places that believe hiring QA is useless, because "everyone should do QA".
I'm thinking of it not as a title, but a role. Often times the 2 are not related
Sorry, I'm not native English. What would be the difference?
A title is just something a company calls a particular job. A role is what that job actually is. So a lot of jobs might be called "QA engineer", but not fitting the intended role
Gotcha. I mean, all software engineers should do some QA engineering, but we have QA engineers who are the experts and "QA coaches".
Dedicated to testing, absolutely, but they don't necessarily require expertise regarding implementation.
But testing... Is that really necessary?
Yes. But I don't really count testing as part of code review.
…we haven‘t been sued by our customers for bad code!
Yes thats due to testing.
Can you prove that?
…
Honestly documentation is at least as important as code , but I get you
And isn't testing even more so!?
How do you know what's it supposed to do, if no one actually wrote that down, other than
As a person.
I would like it to work
So i can do the things.
To be fair, at least that's something...
Or maybe for testing the documentation is the code. The code does this, write a test that accepts it does this.
I like the concept of describing things in scenarios and having data objects embedded in the scenarios. I think gherkin if a bit too restrictive, the same way user stories are, but a more natural verbose scenario that was parameterised with variables tied to actual data makes it explicit what is supposed to happen and what data the system will consume, create or manipulate.
E: there is of course other types of documentation available
Agree, I would put tests higher than documentation, I just got to documentation first and was triggered enough to comment immediately
Hehe, no hate here - I likewise was spinning off of what you said, carrying it forward:-) (bc those are quite important matters indeed!)
Block your calendar.
Periodic office hours are tremendously helpful as well.
Block an hour, once or twice a week, for people to come by an ask you (and your team) about literally anything they want. And open it to everyone at your organization. Have your team stop answering one-off questions and tell people to bring it to office hours.
Team leads and tpms should help with logistics, messaging and hand-slapping.
That would imply that people check your calendar before randomly calling. I get calls on Teams even when setting it to appear offline.
Don't answer
People call you directly without asking? Ignore them ffs.
Direct co-workers usually ask, it's mostly higher-ups that do it. I guess they think that they're important enough to do it. I absolutely ignore it if I don't have time or are on break.
FYI teams has a setting to block direct calls and an automated voice message for missed calls.
Mine has been set to reject calls and play an automated message letting the caller know to ping me first on teams ever since my company decided it was an amazing idea to forward every employee's office phone number/calls to our God damned teams account.
I despise spam calls and refuse to take calls unless asked first
even those higher ups need to learn that their underlings can only be productive when they aren't being prevented/distracted from being productive.
Lol I get calls during calls