• 0 posts
  • 25 comments
Joined 3 years ago
Cake day: August 18th, 2023
  • To be fair even the most technically adept person can have tunnel vision where they start digging before ruling out all the simple stuff. Yes it can feel tedious and a little condescending to follow all those steps, but you get humbled the first time it really is just an unplugged cable.

  • I feel like there’s a specific peak between total technical ignorance and a weary understanding of how fickle technology can be. On this peak is the height of arrogance, where you believe you’ve really got everything figured out. Part of learning is understanding that, yes, sometimes you really did just forget to plug the modem in.

  • I definitely agree, but that’s true of any system. The particulars of the pitfalls may vary, but a good system can’t overpower bad management. We mitigate the stakeholder issue by having BAs that act as the liason between devs and stakeholders, knowing just enough about the dev side to manage expectations while helping to prioritize the things stakeholders want most. Our stakes are also, mercifully, pretty aware that they don’t always know what will be complex and what will be trivial, so they accept the effort we assign to items.

  • Honestly a little confused by the hatred of agile. As anything that is heavily maligned or exalted in tech, it’s a tool that may or may not work for your team and project. Personally I like agile, or at least the version of it that I’ve been exposed to. No days or weeks of design meetings, just “hey we want this feature” and it’s in an item and ready to go. I also find effort points to be one of the more fair ways to gauge dev performance.

    Projects where engineers felt they had the freedom to discuss and address problems were 87 percent more likely to succeed.

    I’m not really sure how this relates to agile. A good team listens to the concerns of its members regardless of what strategy they use.

    A neverending stream of patches indicates that quality might not be what it once was, and code turning up in an unfinished or ill-considered state have all been attributed to Agile practices.

    Again, not sure how shipping with bugs is an agile issue. My understanding of “fail fast” is “try out individual features to quickly see if they work instead of including them in a large update”, not “release features as fast as possible even if they’re poorly tested and full of bugs.” Our team got itself into a “quality crisis” while using agile, but we got back out of it with the same system. It was way more about improving QA practices than the strategy itself.

    The article kinda hand waves the fact that the study was not only commissioned by Engprax, but published by the author of the book “Impact Engineering,” conveniently available on Engprax’s site. Not to say this necessarily invalidates the study, or that agile hasn’t had its fair share of cash grabs, but it makes me doubt the objectivity of the research. Granted, Ali seems like he’s no hack when it comes to engineering.

  • For your vector issue, I’d go the route of some static examples if possible. Do you have a way to manually work out the answer that your code is trying to achieve?

    For side effects, that may indicate what I referred to as tightly coupled code. Could you give an example of what you mean by “side effect”?

  • For unit tests, you should know the input and expected output from the start. Really responsible devs write the unit tests first, because you should know what you’re going to put in and what you’ll get out before you start writing anything. If you find yourself making the same mistakes in your tests as you do your code, you might be trying to do too much logic in the test itself. Consider moving that logic to its own testable class, or doing a one-time generation of a static set of input/output values to test instead of making them on the fly.

    How granular your tests should be is a matter of constant debate, but generally I believe that different file/class = different test. If I have utility method B that’s called in method A, I generally test A in a way that ensures the function of B is done correctly instead of writing two different tests. If A relies on a method from another class, that gets mocked out and tested separately. If B’s code is suitably complex to warrant an individual test, I’d consider moving to to its own class.

    If you have a super simple method (e.g. an API endpoint method that only fetches data from another class), or something that talks with an external resource (filesystem, database, API, etc.) it’s probably not worth writing a unit test for. Just make sure it’s covered in an integration test.

    Perhaps most importantly, if you’re having a lot of trouble testing your code, think about if it’s the tests or the code that is the problem. Are your classes too tightly coupled? Are your external access methods trying to perform complex logic with fetched data? Are you doing too much work in a single function? Look into some antipatterns for the language/framework you’re using and make sure you’re not falling into any pitfalls. Don’t make your tests contort to fit your code, make your code easy to test.

    If ever you feel lost, remember the words of the great Testivus.

  • I’ve had no trouble setting up jellyfin on Roku, Google/Android, and FireTV. It seems AppleTV is the only major one lacking support right now, and that will hopefully be addressed soon.

    I tried out Plex (and Emby) before Jellyfin and was annoyed how much functionality was locked behind a paywall even though I was hosting the content myself. Jellyfin is completely free and lets me add as many users on as many devices as I damn well please.

  • I base my opinion here on my experience with the Python discord, which is probably one of my favorite haunts these days. It excels at helping newbies, of which there are many each day, because their questions are quick to answer and can be handled almost instantly by any decently experienced active user. It’s the more specific or advanced questions that languish there, because it’s less likely that someone experienced with that particular domain will happen to be online. It doesn’t need to concern itself with archival quality because no one expects answers to be referenced later.

    So I think both types of communities can play to their strengths without diminishing their quality. The chat rooms can answer the simple, open ended questions that don’t bring value to SO’s database of knowledge, and the more complex and advanced questions can have a better chance of being seen and answered with valuable insight on SO.

  • I think the issue is that, as a new dev, you also have no idea where to go for the type of help you need, and SO is always at the top of the search results. I’ve found that discord servers are better for helping newbies because it allows more experienced users to interactively teach them how to ask questions and how to read documentation. Handing someone a URL and saying “look it up” is pretty helpful for a newbie, but that’s discouraged on SO since answers are much more permanent and links degrade over time.

    Maybe SO needs some way to direct those who “don’t get the site” to a more chat-room like community where they can get their very common questions answered quickly rather than posting a duplicate question that no one wants to take the time to fully explain in a single answer.