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. especially with a distributed system of course, you still need to try to be smart with the logging edit: not to mention you sometimes don't even have the same environment available, e.g. when talking about some esoteric HW
    11
  5. C doesn't have long build times
    11
  6.  @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
  7.  @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
  8.  @sysarcher  as long as you reference the data in your behavior, they aren't truly separate. You can do without that referencing, but it generally requires a lot of copying and moving ownership. OOP is good for enforcing invariants, which may or may not have a performance impact. It really depends on your team, the goal, and how those are expected to evolve. Biggest problem with OOP I see is the misunderstanding that the class is responsible for every possible behavior, which just ends up a mess of dependencies and responsibilities.
    7
  9. I've never seen "loaning" programmers working, regardless of language, or library, proficiency / commonality. It takes way too much time to get people up and running, understanding the context and familiar with team specific tech restrictions (e.g. specific bus or accelerator usage, though rarer in web dev). I do agree that at least some common guidelines of languages and tech used is a good idea, especially for teams working on the same product. Very good presentation.
    6
  10. 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
  11. He has made a video in the past about preferring pair programming, and seeing it as valid continuous code review.
    5
  12. nothing wrong with a flags-variable
    5
  13.  @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
  14. not really, pretty much all of these seem to be on the programmers themselves
    4
  15. TDD works poorly for visuals, but it still works well for testing the ViewModel / Controller logic
    4
  16. 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
  17.  @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
  18.  @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
  19.  @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
  20.  @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
  21.  @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
  22. 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
  23.  @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
  24. 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
  25. 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
  26. it's really difficult to get people to stay on topic in stand-ups (whatever the frequency), especially without coming off badly
    2
  27. 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
  28. Accelerate book goes through studies, mostly a single one, that indicates that integration is better than inspecting / gatekeeping
    2
  29. 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
  30. 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
  31. 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
  32. 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
  33.  @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
  34.  @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
  35.  @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
  36. 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
  37.  @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
  38. 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
  39. 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
  40.  @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
  41. Indeed. OOP does NOT mean there is not still Plain Old Data around
    2
  42.  @_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
  43. 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
  44. I guess BDD somewhat addresses that?
    1
  45. 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
  46. 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
  47.  @DerDoMeN  Yeah, I'm not sure I agree with him on that, but lacking the experience, I couldn't really say.
    1
  48. he outlines some benefits of having common testing and pipeline environments
    1
  49.  @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
  50. 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