You must log in or register to comment.
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
Coders who complain about documenting and tests are coders I don’t want to work with
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.
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.
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
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.
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.
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.
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 solved this dilemma by quitting and becoming a school bus driver. Now I only have to worry about middle-schoolers threatening to shoot me.
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.
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
I really don’t understand how a 5-10 minute meeting can get in the way of progress
primarily because both context switching and progress builds upon itself so stopping & switching has more impact than those 5 or 10 minutes suggests. (ie. you can stop a car from rolling down the hill with just one finger if you do it early enough but in reverse).
also standup meetings have a way of getting longer and covering more ground that what was initially planned for. (ie meeting mission creep)
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
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
