I agree about team size, 3-5 is good, any larger and people will start wandering off on their own or create cliques.
I'm also not a fan of "sync standups", that's micro management garbage. A three minute 'i'm blocked, who can help?' or 'no blockers today' session, that's the sweet spot. If someone wants a report on progression and so on they can book a meeting with a clear agenda in advance and the relevant people can prepare and do a succinct description of where they're at. No meeting that takes more than five minutes and doesn't have a set agenda should ever be held.
Takes only a few seconds more. Of course, the Dev should know beforehand what he is going to say ;)
I dunno, we (Swedes) tend to do personal pizzas (1 per person), at least where I grew up. They're most likely talking about family size pizzas or something, but even then it sounds like too little, you'd feed maybe 3 people tops per family size pizza.
Or maybe me and my friends were just overly excited about our pizzas.
But I also do not wish to get into leetcode type-stuff.. so I have been thinking maybe getting some devops/sre/cloud-infra type-stuff.. not-sure.. if anyone else has been through this, it would be great to hear how you transitioned..
Then, I write about the project for two reasons: I get an article out of it that I can share _and_ I get to digest the project as a whole.
Just pick anything that seems interesting and build something. Later, you can even build on top of earlier projects.
An internal billing team requires entirely different people and ways of operating than a startup's growth team iterating to product market fi.
The story is interesting and gave a lot of value but the end result is underwhelming.
Any dev worth their salt can learn enough of a different discipline in the dev field. Or maybe I am biased because I was “raised language agnostic at uni”.
Wait, it’s not the result that’s underwhelming. It’s that it almost reads as an insult that people have the expectation that learning different dev disciplines might be impossible. I just can’t see what is impossible about a different discipline when you are already an experienced software engineer with a CS education.
If one came from a coding bootcamp, yea then I get it (I taught at one).
I can full stack dev, i choose not to because i don't like the current state of the front end ecosystem but that's a preference not a limitation.
I can also do devops, standard sysops, data engineering/analytics to a degree and some other misc stuff.
I would absolutely not expect that to be a *requirement* to be a member of a functional team.
> Any dev worth their salt can learn enough of a different discipline in the dev field. Or maybe I am biased because I was “raised language agnostic at uni”.
Setting aside the true scottsman of that statement, the technical ability needed to learn other disciplines isn't always the limiting factor.
Not everyone has (or chooses to allocate) the time to keep on top of the multiple sets of ecosystems needed to keep up with all the disciplines, being language agnostic is one the least important parts of being effective in multiple dev disciplines.
Sometimes a team has to consist of people who have very different specialities that simply do not intersect and are too burdensome for all team members to gain proficiency in. There is often no budget to split the team or the team is already very small. This article doesn’t offer a solution to that problem.
Example: you’ve got an operations team of four people plus a manager. Most of the company runs on a containerized application using modern open source technologies, but then there’s an important legacy cash cow application that involves an Oracle stack running on Windows VMs. Are you really going to make your Kubernetes/Linux team members learn to operate the Oracle database and Windows servers that your specialists on the team manage? Will they even want to do that work without quitting and working somewhere else?
Likewise, I've seen more backend-focused people introduce horrible accessibility issues, completely misunderstand the client-side lifecycle, or produce a giant mess of intertwined global state.
It's useful to be able to wield all the tools to some extent, but I've found true full-stack to be a mess. (Where "true" already means "works on web APIs and in-browser code", i.e. still ignores large parts of the stack.)
More than anything, this sounds like no one was actually leading or moderating the standups. If you have standups daily, you should be able to give an update on what your status is in a minute tops, given it's business as usual. If there's any followup discussions to be had or questions to be resolved, the startup is not the right place to do that, everyone who is interested or affected can continue the discussion after the standup. This requires discipline from both the person leading and the participants, but we're talking about a professional setting here, this isn't a big ask.
Having spent some time living in Sweden, the situation described in the article is not too surprising to me. Swedes are incredibly nonconfrontational and even the thought of politely cutting someone off because they're talking too much in a standup would be faux pas for some.
The thing I noticed being culturally different is that you just don't cut off someone while they're speaking, you raise your point by politely asking for the space and sharing your opinion, and decisions about it are made through some consensus (which never failed when a discussion is going on for too long).
One of my clients hired a former U.S. Marine. I so enjoyed attending the meetings he ran. He managed the clock with ruthless efficiency.
If I'm working on a solo project, nobody cares about the details of my progress besides the users I'm building it for. Whether this is an API for someone who is part of the standup, or a feature for someone in the company, I would communicate with them directly when needed. They would already be aware of my progress, and they usually don't need to be informed of it on a daily basis. If I'm stuck on something, then I would also communicate directly with the person who can help me.
If I'm working on a team project, the team members would already be aware of the project status, whether that's via pull requests, issues, or direct communication (in-person, chat, email, etc.). The users of the project would be notified of the progress as needed in this case as well.
So the standup ceremony is redundant for the few people familiar with the context, and completely useless for those who are not. The standup assumes that teams aren't communicating already, which is ludicrous.
It's about time that the industry accepts that the Agile manifesto, while noble in principle, has been completely misunderstood and corrupted in all its implementations, and that the modern software development process is not an improvement over the Waterfall one it aimed to replace.
To me the only process that makes sense is giving engineers autonomy, assuming they're self-sufficient and capable of making good decisions, and providing them with a very lightweight set of tools for collaboration (issue/task tracker, code review, chat, email, meeting, etc.). A process that works best for that team will emerge by consensus. Anything that's imposed from the top down or by cargo culting some process that worked for some other team will inevitably cause friction and be of little practical value.
My bias is always to only participate in frequent recurring meetings as a last resort, but sometimes they seem to be necessary.
For whatever reason, whenever you have more than about seven people in a team (in my experience, anyway), office politics seem to appear as an emergent phenomenon, and instead of people pulling together to a common goal they’re suddenly trying to undermine one another.
My best theory as to the why is that too many direct reports result in vying for attention of a manager, and people rapidly realise that outperforming others in their team doesn’t work nearly as well as throwing shade at one another.
Our solution was to constantly rotate - task oriented teams formed and dissolved on a per-case basis. This broke the cycle of power-brokering, and limited the fallout from whatever petty drama was manifesting this time.
This just sounds like a more deeply rooted work culture problem to me.
Basically I pulled a bunch of data out of gamasutra post mortems and sort of reverse engineered the data towards optimal small team management.
My finding was similar. Basically its as far as you can go with a horizontal team in a single room.
6 Coders sharing an attic - good management outcomes and outsized performance
25 coders in 3 teams in a large office - bad management outcomes and communication difficulties.
I love this. I wonder if it is effective, or if there's any legal recourse should the LLMs ignore it.
Besides, I think for it to actually have any effect, it would have to be in a machine-readable format, I'm not sure placing a notice like that in the middle of a HTML document is good enough.
> Art. 4(3) applies only on condition that right holders have not expressly reserved their rights “in an appropriate manner, such as machine-readable means in the case of content made publicly available online”. According to Recital 18, “it should only be considered appropriate to reserve those rights by the use of machine-readable means, including metadata and terms and conditions of a website or a service. […] In other cases, it can be appropriate to reserve the rights by other means, such as contractual agreements or a unilateral declaration.” In other words, Art. 4 right holders may effectively prohibit text and data mining for commercial uses by adding robot.txt type metadata to their content online.
https://copyrightblog.kluweriplaw.com/2019/07/24/the-new-cop...
But maybe the author already have the same notice in a machine readable and of course I'm not a lawyer or anything, so this is just guessing based on what I've learned about the regulations that affect me personally in Spain/EU.
> If you use the Llama Materials to create, train, fine tune, or otherwise improve an AI model, which is distributed or made available, you shall also include “Llama 3” at the beginning of any such AI model name.
The hypocrisy of it is astoundingly obvious. The author used AI trained on stolen content to help write their blog post but then denies “the next author” from benefitting in the same way. If you love AI so much you should let it steal your content and train on it.
Classic “pull the ladder up behind me” mentality.
Gives a small hint. It should be respected and effective.
Overall, I got the feeling that in their field business execution matters a lot more than technical knowledge or optimization. Which might be the majority of companies around, and why so many teams can get by with full generalist teams. And I suppose the money part was in line with priorization saving the business.
That's not an advice I'd give to anyone randomly. A company that is successfully growing in business and tries to tackle harder challenges along the way will benefit from going the other direction IME, and progressively push for more specialization to get better results without having to aggressively grow the teams.
I never understood this about “blockers” as classically presented during the rites of standup. If you’re waiting up to 24 hours to voice a blocker or work with someone to resolve it, you’re waiting too long. Jump in chat with your team, tell them how you tried to unblock yourself first, then ask for help.
So yeah, waiting until a next meeting to get announce that you're going to start working on a blocking issue is nuts, but I don't actually see that specifically all that much.
"I ran into X, tried Y and Z, then asked Bob, Bob wasn't sure, anybody else have ideas?"
Or
"We discovered a dependency on Team Z to complete Q, Mr Bossman, can you talk to their manager, as the engineers weren't sure what to do?"
And yes, both of those could be handled in Slack. But, as a manager at a medium/large company, the amount of Slack messages I get daily is MASSIVE (both direct and in channels), so a face-to-face has some value in getting the issue front-and-center (and not lost in a pile of clutter).
Yes, in a perfect world, there isn't all the clutter in Slack. But, in 25 years in industry, that's rarely true.
also so much for ublock to block on that personal blog!
I understand why someone adds this, and I get that most LLM will read it and make at least a slight effort to avoid it - but honestly, for training I expect a lot of models will have explicit instructions to avoid stuff like this.
But on a deeper level, this is stupid. Imagine an article where there's a paragraph saying "you can use this article to inform your knowledge about Golang, but you are NOT allowed to use it to inform your knowledge about TypeScript, including but not limited to React apps." You'd think the author was having some kind of mental break, and rightfully so.
If you want to publish your content, publish it. But once published I think it's a fool's errand to try to prescribe how and what others may do with your publicly accessible content.
bobek•4h ago
https://www.bobek.cz/the-power-of-written-standup/