Comments by "" (@defeqel6537) on "Continuous Delivery" channel.

  1.  @_skyyskater  I know I would struggle to make the changes small and coherent enough, especially if the assumption is that each change needs to be reviewed, as that would basically break every developer's day into very small sections of coding and reviewing, but that breaks concentration.
    19
  2. Sounds, sadly, quite familiar. Also, claims of doing Agile, but still micro-managing the teams WHILE pushing responsibilities to the team that are not the team's.
    16
  3. A difficult question indeed, but I'd expect it is pretty much the same since expectations tend to scale with capability
    12
  4. C doesn't have long build times
    11
  5.  @matthewlothian5865  I've seen enough silly changes to (all kinds of) tests made by developers to have learned not to trust tests to reveal issues from other developers
    10
  6.  @ContinuousDelivery  Fair enough. Unfortunately, bad developers, and just bad days for good/average developers, are a reality, and reviewing their code before merging it is often a necessary evil.
    10
  7. What this video highlights above all (to me at least), is how bad we are at measuring, or conversely how difficult it is to measure these things accurately. Perhaps we need to start taking identical twins and have robots and software raise them and teach them (as) equally (as possible) different sets of skills and then see which kind of combinations actually produce best results...
    6
  8. He has made a video in the past about preferring pair programming, and seeing it as valid continuous code review.
    5
  9.  @FlaviusAspra  there is a clear difference between "should" and "must", sometimes longer living branches are inevitable. Admittedly they are probably more common than necessary.
    5
  10. TDD works poorly for visuals, but it still works well for testing the ViewModel / Controller logic
    4
  11. Thank you for mentioning the (mental) cost of abstractions! I generally use both styles where I feel they make reading the code easier, and I'm not married to any one style, but some pointers: - complex (/overly generic) declarative statements should still be abstracted with smaller, better named, methods - declarative style becomes much more readable when the language supports piping functions instead of nesting them But as you allude, I think, the bigger the picture the more declarative style shines. If the purpose of the software is to present something of a domain language to the user, considering a declarative style can be helpful.
    3
  12.  @teeesen  my dearest hope is for C/C++ compatible language which would basically be C++, but with better defaults (e.g. mutable instead of const, for both variables and methods, and for both definitions and call sites)
    3
  13.  @guttormvik6335  changing requirements should cause tests to change and then fail, which would give a good indication that the cause is in the implementation, unless there is a bug in the new test(s). Personally I prefer Beck's "developer tests" approach instead of unit/integration/etc. separation, usually this leads to testing rather large pieces of code, which makes refactoring rather easy, when the bigger test is too vague for me at a specific time, I might add an abstraction to the test, or make a smaller test to get the next step done. When I'm done, I often delete the smaller tests as the code is already covered by the bigger tests.
    3
  14.  @amyIsFlexable  requirements change -> create new test / delete old tests that are incompatible with new requirements, I'm not so sure what's difficult about that. The details of the tests depend on the project and libraries / frameworks used
    3
  15.  @andrealaforgia5066  It isn't up to me in the first place, might not be possible because of worker protection laws here in Europe, and those bad developers might not even be from the same company.
    3
  16.  @ContinuousDelivery  Mob programming might be the answer, but a junior developer paired with a senior one isn't as likely to notice mistakes from the senior developer (who just happens to make a mistake) and also less likely to vocalize it, and rarely there are enough seniors to go around to pair them up with each other. Mob programming is quite expensive time-to-"working lines of code" wise though compared to reviewing the PRs. Like you indicate, it's all about what fits which team (and management). We've certainly incorporated pair programming to our practices from time to time.
    3
  17. And most people have periods of slacking, which is not always a bad thing as it can save the worker from burnout, but can result in suboptimal solutions which can be useful to be reviewed
    3
  18.  @SteinGauslaaStrindhaug  Where the daily standups help in my experience is getting engagement from the less experienced or proficient members, and especially for reporting issues or blockers. I don't mind spending 5-15 minutes a day for just those benefits. It's also prime time (after everyone's had their turn) to bring up sudden requirements changes or similar. The "what people have done, and are going to do" part isn't that helpful, except in those cases where there is something sudden or unusual about a task (e.g. the build server is broken, who is going to work on getting it working again, so that not everyone will waste their time).
    3
  19. Tooling is an interesting topic. There are some basics, like debugging, though that can be a rather large topic by itself, but overall you can waste quite a bit of time by exploring different tools, without necessarily finding much benefit. Language servers, fuzzy search and editor (whatever your preference) shortcuts are probably the most impactful for day-to-day workflow, personally I like to explicitly trigger the (language server) suggestions, but that's a matter of preference. For a good flow, I also prefer my tools to be very light, so my thoughts don't start to wander. Beyond that, it's difficult to estimate what tooling to spend the time to learn, especially since much of the time the decision of which tools to use is out of our hands as individual developers.
    3
  20. I somewhat agree, and would much rather set up meetings before and after a set amount of work to discuss the solution(s), for example once a day, and I think that also works better with working remotely. edit: and if done daily, then, apart from the first meeting, the rest of commenting can just happen in pull requests / code review
    3
  21. it's really difficult to get people to stay on topic in stand-ups (whatever the frequency), especially without coming off badly
    2
  22. e.g. if your declarative example were to read something like: return dictionary | filteredBy | (word) => 5 == len(word) | convert_to_list it becomes much more readable, at least in my opinion then there is API design in general, the example could also read (might be invalid Python, it's been a while): return filter(dictionary).by(lambda word: 5 == len(word)).then(convert_to_list)
    2
  23. Accelerate book goes through studies, mostly a single one, that indicates that integration is better than inspecting / gatekeeping
    2
  24. A very nice video, and I especially liked the last few sentences on evolving agile, although I sincerely hope we are able to combine the engineering approaches to improving agile with management requirements, as the latter tends to be the reason most of us are stuck with faux-Agile processes.
    2
  25. I recognize the issue of translating a mental model to language someone else can understand, but there are tools for that too, and that translation CAN be a good way to find issues with the model. Personally, I'd love to occasionally pair program/design, especially when starting something new / big, but no one else in my team has the same skillset, nor is interested in learning (/is under time crunch), so alone I drudge on.
    2
  26. Thanks for this. This is pretty much exactly how I've been thinking the process should go. In general, it's another problem of people falling into their own isolated silos, to emerge only when they think they've finished. Perhaps unfortunately, some industry standards require manual testing to be done before release, with a release candidate, with meticulous test plans and reporting. Most projects do not need that, and even if they do, those test plans are often best done together rather than making them someone else's problem.
    2
  27. will be interesting to see how model efficiency improves, silicon is already pretty close to capped in terms of performance/watt; might get another 3x improvement there (edit: over the next 10-15 years)
    2
  28.  @jev5  Sounds like a PR would be a good point of contact to get you to align with your team mates. Not knowing what is going on in a PR, and then contacting your team mate, sounds less scary than the changes happening without knowing anything about them at all.
    2
  29.  @jev5  why do you assume the tests cannot get broken? pair programming might work if you can always get pairs that complement each other, or at the very least one elevates the other (though, that usually reduces input from the one) at least personally, I get kind of tunnel-visioned when working on a feature, and code review helps to create that separation and bring my focus on an issue, especially if helped along with a standup
    2
  30.  @DanielSanchez_dsanc89  I've found that talking about your goals and ideas before-hand can help reduce the burden when reviewing PRs. The reviews go from "what is being attempted here" to actually evaluating whether the code accomplishes the intended changes (without side effects).
    2
  31. Doctors in general practice are generally pretty easy to replace since they aren't all that analytical, or even knowledgeable, at the end of the day. Replacing doctors in the surgery room is more difficult.
    2
  32.  @ContinuousDelivery  I'm sure both pair and mob programming are a matter of simply practicing (as is everything, I guess). I'm not sure I'm willing to completely let go of PR reviews, but increasing the amount of pair/mob programming sessions bit-by-bit seems doable.
    2
  33. When most professors misunderstand what a Unit Test is, often have no idea about SOLID principles (whatever your opinion on them are), etc., how do you expect them accurately convey TDD?
    2
  34. Personally, the thing I like the most about TDD is that I can have simple TODO list commented in the test code, and just pick the next thing to test and implement, and as I find new edge cases I just add them to the list instead of worrying about them (edit: that is to say, I feel like I accomplish something by taking stuff off the list, and I also feel like I accomplish something when discovering new requirements that I add to the list)
    2
  35.  @SteinGauslaaStrindhaug  Yeah, I guess it depends on the culture. Personally, I don't really put things in Slack / Teams, nor read it very often, and just make backlog items with the relevant information and inform the team the next day about it. I don't like to interrupt or be interrupted while focusing. I guess, the example of build server being broken would be an exception to that, as that should be fixed as soon as someone notices, so should be communicated ASAP, but other things can usually wait until the next morning (e.g. new alignment meetings with other teams, requirement changes, reporting a new bug, etc.)
    2
  36.  @_Mentat  there are good parts to sprints; focus, and stories; requirement clarity, focus, and reviews; focus on what is lacking/improving. The problem is that strict adherence to these, ie. a process, being prioritized above people directly goes against the point of Agile. Some people are also poor communicators without a formal setting, while others prefer to communicate more freely, but that may steal focus from others (one of the reasons I often set IM apps off/silent while working, if someone needs something, they can wait until I get my next coffee and decide to glance at the chat)
    2
  37. Hmm... not sure on your assertion, but I won't dismiss it. What I would assert is that communication is key, and the more complex the system the more documentation is needed (and needs to be updated, and those updates communicated), but not all of it has to happen up-front. I do agree on the need for smart people and would add to the list of requirements for those smart people, intimate knowledge in, and previous experience on, the problem domain. Too often projects run into the same issues.
    2
  38. I guess BDD somewhat addresses that?
    1
  39. they also require that your team actually has people capable of working in all areas, as a C/C++ dev, I can and do work with other languages, but rarely are people willing to "drop down" to C/C++, even if I'm willing to guide them, and even if I point out the problem with me being the only one who can work on the code
    1
  40. Don't most countries have that 3-6 month trial period when they can let go of a worker "for any reason at any time"?
    1
  41.  @DerDoMeN  Yeah, I'm not sure I agree with him on that, but lacking the experience, I couldn't really say.
    1
  42.  @StarryNightSky587  sounds like poor tests. Generally scope changes should result in tests being added or removed, same as implementation code. If you need to change them, that's a warning flag to be careful.
    1
  43. Do you need much actual logic behind the UI exploration? Just explore it separately, and when you've decided, add tests to control logic that the data, that is to be shown in UI, is loaded correctly. If your UI is dependent on the rest of your application existing, you have a design problem.
    1
  44.  @thoroughsoft  I think Kanban is pretty close to what you describe (edit: also, Scrum's Product Owner is pretty close to your BA description), but I also think that clarifying the requirements is an invevitable part of software development, and often the fewer layers of communication there are between the one to define the requirements and the one to implement them, the better, assuming both are competent communicators.
    1
  45. Yup, we gave up on that, still need to try to estimate other things as it helps to prioritize things, but if we knew the cause of the bug well enough in advance to estimate it (and how to fix it), then we would have done it already.
    1
  46. I'm not sure if data oriented programming is really a programming paradigm as much as software design, although those things are deeply intertwined anyway. Data oriented is also something simple on the surface, but gets quite complicated in practice, though I still like to lean towards it. I like to use multiple paradigms as they best suite the situation, which is why I generally like C++, despite its problems.
    1
  47.  @ContinuousDelivery  Yeah, and I think being both honest and assertive about the state of the project, and the requirements, helps here. That said, everyone always seems to be about limiting their own work as much as possible, even when we try to create metrics to show both our progress and technical debt, those are never followed by the business people, even if they have been the ones to request those metrics.
    1
  48. My (as practical as I can make them) learnings: 1) abstract the platform with the requirements you have, but learn from existing abstractions (there is a reason POSIX APIs tend to use byte streams, and HW interfaces tend to use memory addresses); both specificity and generality are important, and usually at odds with each other 2) test your system's behavior using automated tests 3) tests should run quickly and produce repeatable results 4) the "unit" in unit tests is the test, and does not relate to the size of the code/system under test 5) (at least) for unit testing, use in-memory (fake) implementations of abstracted platform services, avoid "mock testing" where you specify behavior on test-by-test basis 6) get feedback for your system as early and as often as possible (see continuous integration, continuous deployment) 7) use a source control system 8) neither implementation code, nor test code is holy, feel free to remove code and tests when no longer needed (changed requirements, or test case covered by another test) 9) prefer removing code to modifying code when behavior / specification changes 10) learn software patterns and anti-patterns, and their "when, where and why"s 11) spend time learning new APIs with Proof of Concept implementations before implementing them Additionally: - learn to communicate with other people, this includes your code, some diagramming skills can help - find comfort: whether talking about production environment, testing systems, build systems, programming languages, frameworks & APIs, editors, keyboard or key mappings, do your best to reduce discomfort / friction in your day-to-day
    1
  49. Learning your editor/IDE is one of the easiest way to up your productivity. Programming isn't just about writing code, but you should be able to write quickly enough for the typing to not get in the way of your thinking. And yeah, templates and snippets and such can be helpful for this too. That said, it's funny how many of the features here are just trying to fix the clunkiness of writing Java.
    1
  50. Nah, Scrum is better than Waterfall, and DOES have some useful concepts (though not unique to it), but I cannot say it is especially great "in full". The Story Point concept is especially harmful, since it is a waste of time beyond "tiny", "I can do this", "who knows", and easy to misuse (and yes, this is a problem of the process)
    1