You must log in or # to comment.
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.
I worked freelance for like a decade. Then I joined a “real” studio. Literally 80% meetings, team meetings, morning stand ups, presentations, documentation, and senior reviews, then 20% actual work. My old boss was great with time management but he left and the new leads would lock you into a 3h meeting, most of it to discuss other people’s work, then expect you to make 3 days worth of edits in 3h.
I feel this meme hard.
The idea that coding is the only part of your job is “actual work” is where you’re going wrong. The goal is to create robust, well-functioning software that’s documented and fulfills what it needs to do, not write an arbitrary amount of code. Your job is more than just doing the part you like.
You sound like a middle manager that brings a net loss to your workplace and justifies their job as crucial because without you, the coders would all be running around the office slamming into each other like 2 year olds.
Coding is the only job. Period. The rest is housekeeping. Much like digging a ditch. It’s not going to get dug if you sit around talking about logistics and reviewing all the other ditches or wasting my time telling me again and again how the ditch needs to be dug. Nor needing hourly updates on how the ditch is coming along, so you can arbitrarily make changes.
If you think I “just don’t get it”, then that totally explains your irrelevance in the work place. Because companies have long lost their way and have prioritized the structure well beyond what they are actually meant to do: get shit done. But then you sound like the type that believes companies are crucial to our success because they funnel money back into the economy and keep society afloat (narrator: they don’t), so I’ll say good day to you sir.
If you want to do the software equivalent of digging a ditch that’s cool, but I’m not sure why you would expect to get an engineer’s salary for doing so.
Hey I’ve schedule a 2h Slack meeting to discuss this topic more. Please confirm your availability 🙃
I can relate.
I solved this dilemma by quitting and becoming a school bus driver. Now I only have to worry about middle-schoolers threatening to shoot me.
Honestly documentation is at least as important as code , but I get you
And isn’t testing even more so!?
Agree, I would put tests higher than documentation, I just got to documentation first and was triggered enough to comment immediately
Bonus: good tests can also serve as technical documentation.
Though I have to disagree with the notion that documentation is as important or more so than code.
Documentation is certainly near the top of the list and often undervalued. I’ve worked on a project where documentation was lacking and it was painful to say the least.
Without documentation, changing or adding features can be a nightmare. Investigating bugs and offering support is also very difficult. But without code, you have nothing. No product, no users, no value.There are (inferior) substitutes for documentation: specialized team knowledge, general technical expertise. These alternative pools of knowledge can be leveraged to create and improve documentation incrementally.
There’s no replacement for the actual functionality of your applications.Hehe, no hate here - I likewise was spinning off of what you said, carrying it forward:-) (bc those are quite important matters indeed!)
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
For those of us who read developer code better than PO/PM “english”, indeed code is the documentation, or at least can be. Ofc when the code is thousands of lines long, split between multiple files, interacts with networked resources that you’ve never heard of, sending signals that do who knows what downstream, upstream, sidestream, flipstream, or whatever… yeah documentation can be important too:-). Also when the code is in some other language that you don’t know quite as well.
By “testing” I should clarify that I did not necessarily mean things like user or unit testing - though that stuff has its place too - but rather even more foundational “verify that your code does what it is supposed to do” kind of testing:-). One could argue that that is just straight-up “writing code”, but then too writing documentation could be folded into that as well, e.g. having things like human-readable variable names, Pre & Post conditionals for functions and the like, so it all gets a bit fuzzy here.
And if we are being pedantic, a “quick call?” could save a month or year’s worth of time “writing code”, to ensure that you know what needs / desires to be done. Likewise, updating Jira could save someone else SOO much time, or even yourself down the line when you wonder about something that was never mentioned. So I assume that OP was not taking this all that seriously, and just joking about “yeah, meetings are less fun than writing code”, and we all ofc have to pile on with our further opinions about what’s fun:-).
Oh man, the "quick call?"s are the worst
“quick call?”
“sure, I’ve got time for the two hour meeting this is going to be.”
“Got a sec?”
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.
Ffs you’re programmers, it’s probably super easy to get another job. It doesn’t have to be like this.
Who’s gonna tell them?
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”.
This is my first big career job and in my limited experience I think I support the idea of a second pair of eyes, with a hybrid on automated testing. It seems more comprehensive and thorough than having a single person work on a task (minus code reviews).
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
Dedicated to testing, absolutely, but they don’t necessarily require expertise regarding implementation.
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.
Nah, I think you’re mixing things up here.
“Toxic” is just a label you’re putting on everything you don’t like and you’re also putting a ton of implications behind it.
If Stacy wants a feature, and she’s the official representative, I need to clarify what that feature means. A manager can’t shield me from having to research the technical implications, that’s my job.
Also, you can ignore calls all you want, if there is a genuine need to communicate, you need to have that call at some point. That’s actually your first point in the list above.
I think you never worked in a role above code grunt. As a senior developer, my job is to do all what I described above. I need to do all the technical legwork a manager can’t. I need to write everything down. I need to get feedback from stakeholders. That’s nothing a manager can do and that’s nothing a junior can do.
I code something like half an hour a day.
It’s not a label im making up. Toxic here is a synonym for unhealthy. If someone keeps calling you, interrupting you, micromanaging you, disrespecting your working hours or your focus times, that’s an unhealthy relationship.
Stacy is entitled to regular details, sure. That’s why we have tickets, and daylies and retros. She’s not entitled to asking multiple times day if you’re done yet.
I work above senior, have done management and tech lead. I’ve seen toxic workplaces, and I’ve seen good ones. I recognize the need for all the agile rituals. But that still doesn’t entitle people to call all the time and interrupt you.
None of the things you mentioned were in my description. You made that up completely. I talked about meetings, no scheduling information.
She’s not entitled to asking multiple times day if you’re done yet.
Did I even imply that? No. You made that up.
I work above senior, have done management and tech lead.
Hearing only what you want, not what the other person said makes you almost perfect management material.
Seriously, look at my comments and your replies. You answered to a completely different reality.
I might… Have mixed multiple thread. I’m sorry
I guess every job I’ve ever had has been toxic then. Juniors and to some degree mid-levels don’t usually have any say in things like when to meet
from what you describe it does sound like a nightmare, but you’re ignoring or mocking people that tell you that it is not the norm
How am I ignoring or mocking anyone?
I got that impression from your reply “lol that’s funny, you’re funny” to a completely non humorous comment
Then you took it incorrectly, its mocking my employer more than anyone.
That’s what retros are supposed to be for. To discuss how to improve the process.
lol that’s funny, you’re funny
For real. All the stuff that person complained about is something a manager should be handling. Mine do. It’s very rare for requirements to change for things I’m working on. There’s typically going to be some small changes, e.g. wording of a message or moving things around in the UI, that happen but that’s to be expected and one of the better parts of working in agile. You make something and find it doesn’t work as well as you hoped? Tweak it.
I think the only time things can change drastically is when I’m working on a priority event, AKA something really bad happened for a customer and we’ve got to fix it ASAP. There’s no time to do in depth research beforehand. You just dive in and sometimes you think it’s one thing but it’s really something else or it’s just more involved than you thought.
Exactly. Shit happens, and we might need to adapt and even scrap a whole sprint plan. But that’s super rare, or it should be. But changing the Roadmap after each sprint is just something that happens.
Either way, none of that warrants random calls at all times from colleagues.
But testing… Is that really necessary?
…we haven‘t been sued by our customers for bad code!
Yes thats due to testing.
Can you prove that?
…
Yes. But I don’t really count testing as part of code review.
Not to mention the fact that the more code there is, the more bugs you have.
Documentation and testing are fundamental parts of writing code.
Also, tests ARE THE code, and equally important too! However so many people make the mistake of writing tests after the function, when the benefit is less immediate. They also have the illusion that they are done and have to do extra work. And since they didn’t write the test first, they most likely wasted a ton of time and energy on extra work of testing changes manually
I disagree unless the tests are reasonably high level.
Half the time the thing you’re testing is so poorly defined that the only way to tighten that definition is to iterate.
In this sense, you’re wasting time writing tests until you’ve iterated enough to have something worth testing.
At that point, a couple of regression tests offer the biggest bang for buck so you can sanity check things are still working when you move on to another function and forget all about this one
Problems caught early are much easier to fix than problems caught later. This applies to any project (I’m not a programmer, but an engineer in the traditional sense).
Just “doing it” without coordination and review is a great way to waste a bunch of effort down the line with re-work.
Edit: typo
While i agree with the principal statement, this also requires two things to work:
First: The scope should be defined properly, so people can contextualize what they are actually doing and reviewing.
Second: If the scope is subject to change, or parts of it are unclear, there needs to be room to consider, develop and try different variants
This is were good management is crucial, which includes giving breathing room at the start. What we tend to experience is the expectation of already good detailed results, that can be finalized but still work if things change significantly.
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.
Depends on the team. My team do daily standup and it helps. A lot. “What are you working on today and do you need any help to get it done” is a super powerful question to make sure we’re all focusing on the same priorities and sharing the knowledge we have, especially in a team of mixed disciplines.
Why not reach out to reach to each team member on a daily or semi daily basis to ask that question?
These meetings REALLY get in the way of progress and we’ve been killing it ever since our new manager started doing it like this
When I worked as a PM that’s what I used to do - daily check in about any obstacles that I could clear. Took me a little while to get around everyone but it didn’t waste everyone’s time
I really don’t understand how a 5-10 minute meeting can get in the way of progress
I actually tried a daily slack bot instead. The team HATED it with a passion. And the amount of productivity lost on other teams to a backend engineer blocking a systems designer being blocked by a UX flow etc is insanely large. We have never missed a deadline, hit all our revenue targets, and get much. much larger features done in 2/3rds of the time of the next nearest team. Part of that is because we’ve made sure to reinforce the concept that we are a single team instead of a group of server engineers, backened engineers, frontend engineers, system designers, [removed to protect identity] designers, econ specialists, UX designers, UI artists, and QA working in their own bubble.
I hear you, but I disagree. My people are great at slacking me or each other when they need stuff. We have a great collaborative atmosphere. They set up meetings with each other and with me as needed, and I’ve heard over and over that they really like that. I have weekly 1:1 meetings with each of them, and usually we hang up after 15 minutes because they know what they’re doing and can get back to it.
I mean it really depends on the team. My role is as much translator as anything else. I have:
Infrastructure/Server
Backend
Frontend
Designers (three different kinds)
Performance/Econ specialists
QA
Hearing “Oh I didn’t know that, yeah we need to sync” is a common occurrence and on a team of nearly 20 people we never take more than 15mins. We have shared deadlines, shared goals, and work on shared user stories. Having that moment in the morning to go “okay, am I blocking anyone without realising it?” or “I gotta remember to make sure design knows the spreadsheet won’t have the thing they were expecting today, it’ll be Tuesday instead” is well worth the time.
On top of that, with WFH it’s a really good way to cement the team aspect. I wouldn’t care so much if we were in the office, but all being remote means we lose the “human” behind the screen a lot.
As I said, different teams and different projects need different things, but I’d argue the reason my team is the number one performing in the entire company is, in part, due to this morning time to get that alignment.
The first 3 are why I can’t get any work done anymore. The last 3 I would absolutely love to have more time to do.
Coders who complain about documenting and tests are coders I don’t want to work with
Docs and testing have no bravado, but they’re important. If they’re dragging you down, use your problem-solving brain and find a way to make them work for you.
(Sincerely, someone who doesn’t floss)
That’s why I only code as a hobby.
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.
Nohello.net or whatever the URL is
Thank you! I never knew about that site before.
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!”
