I’m curious about why you think this. I’ve seen complex multi year efforts succeed and continue to evolve with agile principles in mind. What specific part of agile do you think would necessarily cause the issues you mentioned?

Fair enough, at my job the code working consistently is absolutely the number one priority at all times but I can imagine that there are some places where this is not true. If working software isn’t imporant then I agree agile is probably not the right choice

It’s worth pointing out though that having insufficient documentation is not a feature of agile. Sounds more like laziness or misplaced priorities to me as documentation is called out as being useful in the agile principles, just not as important as working software.

I don’t understand what you mean, why would coordinating across a large group be against the agile principles? It sounds like the main issue here is lack of communication and planning which are both important parts of any process including one based on agile.

Planning becomes more important for a larger project but if you hyper focus on sticking to the plan even if things change you can end up delivering something that is not useful for your customers, so I think the principles still make sense there.

Would you rather have working software or a bunch of documentation? If your software is having outages then by definition it is not working. If documentation is the root cause of that then you should fix that by creating enough documentation to allow your software to continue to work per “working software over comprehensive documentation”. Maybe I’m missing something but I don’t see the contradiction here.

Yes, and daily standups are not a requirement of agile in any way. The whole point is people over process and adapting to change rather than following a plan so if standups aren’t working you should stop doing them rather than following a rigid process!

Note that this is failure to deliver on time, not failure to deliver full stop.

I also think a lot of places claim to be agile, but don’t follow or understand the principles at all. Another commenter here is the perfect example of that where they say the opposite of what’s in the agile manifesto and claim that it’s a representation of what it says.

Maybe that’s a fundamental problem with agile. It’s just a set of loose principles rather than a concrete methodology being pushed for by a company and it has therefore been bastardised by consulting companies and scrum masters claiming to teach the checklist of practices that will make your company agile. Such a checklist does not exist, it’s just a set of ideas to keep in mind while you work out the detailed processes or lack thereof that work for you.

For anyone that wants to refresh their memory on the agile manifesto:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

1. Don’t Write Logs by Yourself (AKA Don’t Reinvent the Wheel)

2. Log at the Proper Level

3. Employ the Proper Log Category

4. Write Meaningful Log Messages

5. Write Log Messages in English

6. Add Context to Your Log Messages

7. Log in Machine Parseable Format

8. But Make the Logs Human-Readable as Well

9. Don’t Log Too Much or Too LittlE

10. Think of Your Audience

11. Don’t Log for Troubleshooting Purposes Only

12. Avoid Vendor Lock-In

13. Don’t Log Sensitive Information

The article goes into some nice detail on each of these but those are the 13 practices being advocated.

I haven’t used GraphQL personally but I’ve heard interesting things about it. It sounds like you’ve been burned by it so I’d be interested to hear more about your opinion beyond that you think it sucks if you’re willing to share some more details.

Same here, unless it’s a small PR then I like to nitpick 👍

It’s a meme to say “can’t you just” at my workplace

The best code editor is the one that you enjoy using, because you’re going to be using it a lot.

Let’s do it for real then

One interesting thing I read was that commenting code can be considered a code smell. It doesn’t mean it’s bad, it just means if you find yourself having to do it you should ask yourself if there’s a better way to write the code so the comment isn’t needed. Mostly you can but sometimes you can’t.

API docs are also an exception imo especially if they are used to generate public facing documentation for someone who may not want to read your code.

Agree with you though, generally people should be able to understand what’s going on by reading your code and tests.

Very true and completely agree with your post. I didn’t mean a test in the exam sense more like a COVID test in terms of test design.

I actually think in some ways it’s a good thing to overlook the technical side to a degree as well because technical skills are generally a lot easier to teach than the people skills. Assuming the fundamentals are there at least.

An interview is just a test. Like any tests there are false positives and false negatives. There is a trade off between having more false positives/negatives and generally when it comes to hiring, a false positive is much more expensive than a false negative so many interview processes will end up rejecting good developers.

An interview can’t tell the company whether or not you are a good developer or a bad one. It can only say you can demonstrate certain skills to a certain level under interview conditions which means you are pretty likely to be a good developer.

It’s tough when you get rejections but because of the above factors, unfortunately it’s not enough to be a good developer to pass interviews a lot of the time. You also have to be good at interviewing. The good news is like any skill it can be practiced and if you’re already a good developer it shouldn’t really take much effort to become good at interviewing but it does require practice.

That’s my take anyway. Keep your head up, practice interviewing and you’ll be alright.

But they do tho…

Source: almost every developer I’ve worked with was once entry level

Not exactly programming but recently discovered Logseq and I’m absolutely loving it. Been using it for work but I kinda want to start using it for personal stuff too.

Completely agree, transactions are amazing for this kind of thing. In a previous team we also had a policy of always pairing if you need to do any db surgery in prod so you have a second pair of eyes + rubber duck to explain what you’re doing.

I think you answered your own question in a way. For smaller datasets and workloads which only require one machine, storing your data in memory or on disk locally is probably fine.

When you start getting larger datasets or need to have a dataset that’s consistent across multiple servers, you need something more than just the ram of the server.

At that point it’s best not to reinvent the wheel and just use some kind of pre existing datastore who’s tradeoffs make sense for your use case. Some of these datastores do use RAM under the hood for performance but there are pros and cons as with anything.

Yeah this was meant to be a joke but looking more closely at the chart it actually seems like it has a gradual downward slope between the massive spikes so it might actually be a burndown chart but with massive bits of scope being added to it.

Without the article to provide context I guess we’ll never know.