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

  1. One of my favorite channels to watch, I enjoy the style of the videos :)
    8
  2. Canary releasing is immediately the first overall strategy that I thought could've heavily mitigated many of the global effects of the outage. I'm speculating entirely from this point on, but I believe it couldn't be rolled back since the interaction between Crowdstrike's software interacts with Windows at a low-level and causes the O.S to be inaccessible once the software deployment went live. I believe they have to delete a file through some relatively straight-forward procedure, but it requires manual intervention to some degree and so it is painstakingly slow to recover everything when the downstream IT organizations don't have great remote controls over each individual instance of Windows. Indeed, it is most curious how and why early detection of such a blatant issue was not present here. Perhaps, some testing was neglected?
    6
  3. I'm on conference talk kick lately, watching the various software conferences. Thank you for this. I am coming to the end of the list of talks I've been meaning to listen to, and I am always searching for more.
    5
  4. remote work.
    4
  5.  @cdarrigo  the whole point of tdd is to take small steps though... he says this often.
    4
  6.  @TheEvertw  What a nightmare! Congratulations on getting out of there in one piece! That team sounds like they're real good at engineering, engineering their own problems that is.
    3
  7. Looked pretty real to me. The examples are simple like he explained, it's good design. You seem to gloss over the advice of NOT writing tests across multiple systems. That is bad code and bad test design! That part is tricky on purpose! But there are ways to mitigate those complexities
    3
  8. Well, as Dave mentioned, microservice developers might have different standards from team-to-team. If done separately from the data model, logging that data would be most useful if its all connected together in some form or another (correlation IDs so that you could query it) and that could require disciplined teams to do that. I agree it is lazy. In my experience, you'd be able to create a partial picture from the logs and query it using something like ElasticSearch, but it was hardly ever conclusive enough and mostly a scratch on the surface for something that needed to be further reproduced. This is THE problem and solved with a unique navigation of how teams are organized along with smart solutions that provide the necessary and exhaustive set of logs/metrics/traces for any particular event. I'm mostly drawing from my anecdote and working in an ElasticSearch logging system that had logs but still not valuable on its own without even more context and data. I guess one question would be how easy would it be to add testing for the logs associated with the transactional data? Whereas if you do it separately, you might not be able to test for the existence of logs. It might just require discipline. Maybe if your business is to sell data with logs associated with that data to your customers? Otherwise not sure.
    3
  9.  @berkes  Total agree. Bad devs are hilarious, especially when they're in charge.
    3
  10. That's perhaps the reason why people routinely leave jobs and also why that company is hiring in the first place. They need more labor to fix the problem they continue to facilitate!
    2
  11.  @azena.  Well I appreciate the general observations you've made more than specific scenarios. Certainly a good read, thanks. It makes sense what you have to say about mob programming. I think it makes perfect sense that mob programming would be great for getting some people who struggle with people to add value in a cooperative setting. I haven't yet experienced any mob programming and the amount of pair programming I have has been limited even if it has been my favorite form of collaboration yet. On a side note, I envy you. I would definitely enjoy contracting, but I've yet to break into even the entry level market. Not that inexperience would be a barrier to contracting, but perhaps I just want a bit of reputation before I get into that.
    2
  12. Anecdotal, but I agree. I've worked in a system where observability of things like resources and infrastructure health were there, but we wouldn't necessarily have anything like a "trace" to debug issues or "metrics" to track customer usage. For such a complex system where we needed to make new features quickly, it was odd to see such a lack in business intelligence. Most certainly the observability/monitoring was added AFTER an outage, I became familiar with the tools that observed the production system.
    2
  13.  @TheEvertw  Also I would further agree that designing observability is a bit more involved than simply adding it to production. The same benefits were often sorely needed into testing/staging environments where devs had no clue what was broken and why. Adding monitors retrospectively is great and all for keeping customers from getting angry at your own issues, but it misses the point of adding monitors and thinking about how the overall system might function and what one might expect from it.
    2
  14.  @babgab  I think you should pair program if you can do it. If you're mentally drained, you need to pace yourself, else you risk burnout. Over the course of time, there should be an improvement. I would recommend thinking about what other parts in life you can't/don't cooperate with well when it comes to working with others.
    2
  15. I know this video seems to discuss intermittently failing tests (perhaps due to some asynchronous work) without changing the code, but I also think of flaky tests as tests that fail whenever you make any code change, too. The follow-up questions in fixing tests that fail unpredictably might be along the lines of "are we testing correctly," or "is our code poorly designed," or "is the test poorly designed?" I'd really like a book that really goes over these kinds of intuitions in a more dedicated manner. Perhaps like a testing anti-patterns book.
    2
  16. I liked your last piece of advice to invest in yourself by spending your own time to grow. Generally be engaged in your profession. Good points, thanks :)
    2
  17. Problem might be there is no one catch-all approach to teaching an individual TDD. I think it highly depends and must be tailored to the individual. Thankfully, Dave Farley has been that individual to me.
    2
  18. Probably :)
    2
  19. Developers can say 'no.' If developers had more similar standards, management wouldn't ask for this.
    2
  20. Im not sure what testing has to do with logging, those two are separate! Unless, of course, your product is about logging! Surely you mean that while you always do test, clearer logging has helped a ton too?
    2
  21.  @kayakMike1000  I guess that's one point of view, but my understanding has always been that DevOps means that developers participate and automate the operations side of things along with coding the solution. Your point of view sounds like the common misunderstanding Dave Farley touches upon 7:32 where dev and ops are seen as separate, instead of together. The problem with siloed ops teams is that they simply do not know how and why the system works. They can only guess as to what the engineer was thinking and only after the fact, rather than being involved with development and also engineering a better solution in parallel. So it's a bit more than just developers don't understand how the software operates, it's simply that they don't participate.
    1
  22.  @awmy3109  So how would people start a new project while pair programming then? You don't have to program 100% of the time when you are "pair programming," there's a lot of conversation and discussion involved, too.
    1
  23.  @awmy3109  Well pair programming isn't just about programming, so yes, it is about discussion. You're discussing with the one other person who probably is the best match for the project. So, you would be seeking a second opinion more than blind confidence in their guidance. Pair programming is more of a tool to help alleviate burnout after typing a significant chunk of code (this is why people take pomodoro breaks). When you get mentally exhausted by physically typing on the keyboard and following syntax, it can affect your design choices (I wonder if there is a conclusive study on this, it would be interesting.) and having a second person to take over while you recuperate is great! There are common misconceptions of what pair programming means, for example you can pair program remotely, it doesn't have to be in-person.
    1
  24.  @awmy3109  Well-- you could make the convincing argument that pair programming is just a real-time PR without any delays. Its analogous to trunk based development.
    1
  25.  @Immudzen  Sounds like mob programming.
    1
  26.  @Immudzen  Mob programming should be done sparingly only because it is expensive, it's a good way to "see what sticks" as somebody put it. I think pair programming is far less expensive but just as viable as mob programming. The times that people program alone, it's just using it as a form of debt for delaying code review to a later date due to people being far too split apart in responsibilities. Alternatively, it could also mean that the company is hiring employees that don't actually match well personality-wise (and are somewhat antisocial or dont work together naturally) or they don't know how to interview people. Rhetorically, how many times a day do you speak to somebody that's not directly involved in your code? Whether you are gathering requirements, getting clarification, or pushing back on a feature you're going to be talking to somebody. Nobody can be completely insulated from the real word, that requires communication skills.
    1
  27.  @errrzarrr  Continuous Delivery and Continuous Integration is a healthy practice, his statement on DORA follows. Of course, it all depends on whether its actually 2x, but it certainly is more valuable being that iterative by "having the ability to deliver daily" rather than being stuck in a monthly waterfall process. As a disclaimer, DORA is just a DevOps metric and should only be taken as such, not as a fact. Metrics show a very limited scope of the story and often require much more context to judge whether or not it is meaningful.
    1
  28. Do you consult for groups of developers? Wondering if there are any good studies on applying correct agile models to groups. I was reading a single study on the effect of pair programming for short amounts of time where in pairs that were either made up of heterogenous or homogenous (things like personalities matched, previous existing knowledge) people. There is no silver bullet to getting people to work well together, but perhaps there is a common pattern for finding groups that mesh well together. Do you have any anecdotes that suggest something like that? I feel like personality matches and social skills are overlooked. I personally thought (in University) that it would be odd to be co-workers with some of my peers because of a general lack of social skills. I admit that it was immature of me at the time to think this way though.
    1
  29. Isnt Nix functional? They're probably all at Nix.
    1
  30. Isnt it a necessary step for when theres things like compliance, if you want to be a successful tech org?
    1
  31.  @NicodemusT  Im unsure that anyone here is claiming that testing is absolutely necessary or that 100% is the only correct amount... you'll find the opposite. It's just that people are used to working with tests, and prefer working with others that work like this too!
    1
  32. That reminds me exactly of some of his earlier videos from years ago how he took somebody's (Java? I think) code and re-factored it into unit tests. Although, it was a retrospective, we don't ever see what the previous person who wrote the code was thinking, but pretty similar. One of my favorite video series.
    1
  33.  @TheEvertw  In my experience, the monitoring system was heavily under engineered. There isn't any need for deep insight, but it should be able to state its dependencies and anytime it interacts with them and the chain of errors that occur downstream in other services. I think most of the time that sort of in-depth insight is most visible in the current test suite rather than observability tools. The tools don't need to dive too deep other than to keep track of performance, stability, or user interaction. Rarely did I ever need to tie the specific log to a line of code. The real issue was just tracking down the origin of the error, which service was producing it and the circumstances to reproduce it. I agree that observability should be designed and engineered into microservices. But, first and foremost make sure your microservices are as close as possible to be a "micro" service. After all, observing is the way to attribute your work and how its has reaped benefits from and for your customer.
    1
  34. Thanks Dave, I think the distinction between delivery & deployment is an important one.
    1
  35.  @babgab  Also, your issue has little to do with pairing and more with poor team organization. The team structure isn't good enough to support pairing, you might need intermediate members who can bridge the gap between a web programmer and a graphics dev (assuming there's something worth developing features which requires these two very different kinds of tech stacks).
    1
  36.  @babgab  Yes. It's why im saying pairing has nothing to do with it. You are facing Conway's law indeed
    1
  37. @ It could be, but there also is such a thing like efficient spending and budgeting and good leadership. Conway's law works in this way, too. You might not have the budget to bridge the gap between two very different tech stacks either because the opportunity isn't profitable enough or the money wasn't used in a constrained enough manner.
    1
  38.  @giorgos-4515  No. I think that's the purpose of RAGs.
    1
  39. Agreed with that final point.
    1
  40. ​ @puckpovier1559  A larger team is less flexible. I think that's the entire point of what he was saying.
    1
  41.  @tzadiko  Right, the term escaped me in the moment. That's what interests me
    1
  42.  @AlexGnok  CI (and CD by extension) is going to be hard for your company if its difficult for a lot of your developers to work together in a single branch AND implement automated "QA" into more facets of the software development. Trust is a big factor. Trust in that the tests are correct, that whoever wrote them wrote a useful test. Trusting your "neighbors" is also important, such that they don't break your code when they add a commit. Some of your testing may be manual, but the point is to reduce how much of it is manual. Testing accessibility can be hard when there aren't any tools, you might probably have to write your own tooling to assess the level of accessibility of your app, and it can be useful to do that on some low-hanging fruit to get a small sneak-peek into how a more dedicated solution would help. I am sure there are objective ways to measure how accessible something is. For browsers at least, there is a plethora of automated tools. There's a whole idea of "Web Content Accessibility Guidelines" and automated tools that flag errors on those guidelines. Now, I will risk some controversy here by saying maybe the problem is not that many people are junior level, but rather something much simpler but viewed at a layer higher than simply evaluating individual developers. Maybe that company isn't a shining example on how to write software. Or maybe accessibility isn't very important yet. Up to you if think its worth it. Somehow, somebody thinks it's all worth some $ amount.
    1
  43. You might be shocked to hear that a better salary doesn't fix any of the frustration you feel as a result of "red tape." This is my belief as part of my anecdote from working a period of time in which my employer offered to double my pay. I hope that the only thing stopping you from leaving is preservation of your professional reputation with the company, and even that is expendable if you believe you can help others in a better environment. Once the company can, they will treat you as expendable. Current job market is not very good if you are lacking YOE so most people recommend to not abandon your current job until it improves.
    1
  44. I think a lot of people have the same exact comment. To stand out, would you help out by describing why that seems to be the case? Especially if you consider that a common way to do BDD is to do TDD.
    1
  45.  @DirkBotha  Colorful language is probably the reason if I had to guess. Either way, its not my responsibility. I'm mostly confused on how you've managed to get BDD without following the more common TDD steps to reach it.
    1
  46.  @Trythrow  If you host infrastructure for tons of tech companies, you simply can't not test. Your contracts can force you to pay out so much money if your software fails the customer.
    1
  47. Continuous values is a unique test case I haven't really seen it around much. You could do it up to a certain precision I guess, but if losing some of the precision is inexcusable, you definitely are going to have to write a more thoughtful test. Although, if you are comparing data in a graphical way aren't you tolerating some loss in precision one way or another? How precise are we talking when it comes to people analyzing data? It's like comparing where a web page's form element is in the correct spot to the exact pixel (and somebody missing if it shifted one pixel left or right), that's pretty precise.
    1
  48.  @ЛукашевичАнатолий  Right, it sounds like this depends more on generalized mathematical formulas or certain properties or axioms, which can be difficult to put into code let alone understand them.
    1
  49.  @SirBenJamin_  If you're having to pass in parameters for testing so early in development, whos to say you wont need to do it for a production use case? If it already "broke" once as soon as you changed something as part of your development, it surely suggests and could correlate to an error of that same kind occurring in production in the near future. An added point to adding in a test double or mock thru DI is to avoid all the overhead of bringing in a real engine.
    1
  50.  @SirBenJamin_  The users dont need to know about engines, they can, its optional in a car to know this. Most people just drive them and want them to be reliable. Same thing with the test example.
    1
  51. ​ @ibolcina  If you regularly talk to customer, you don't have to throw everything away. You do a small amount of work, check with them, and then in a roman gladiator style they give you a "thumbs up" or a "closed fist". If they don't like it, then figure out why how to talk to them better, that's it. Worst case scenario is you throw out a week or two of work. The more you work with them, the more you'll understand ALL requirements and that is what decreases the problems you encounter. There's no reason for these cop out explanations like "humans are unreliable and give me a poorly written contract"
    1
  52.  @ibolcina  You might test that your data is persistent and accessible to a customer, not that a table is defined in a database. That is already tested by the database developers... I would advise you to listen to what other people are telling you. Using small notes to describe high level is probably the most ideal amount of "proof of concept" work you should do for anything.
    1
  53. I have this question too. But I think the answer is maybe that it requires a little bit of sacrifice. For me, I would have to pair in the early mornings because of an 8 hour time difference. I'm willing to wake up a couple of hours earlier just to be able to bond with teammates and get some work done :)
    1
  54. Reminds me of VersaLife's slogan
    1
  55.  @ContinuousDelivery  I can notice it in multiple videos, I normally don't since I don't play my volume that high though. It's possible that you can do some noise reduction using Audacity on the audio and see if you can remove some of the background noises.
    1
  56.  @CynicalOldDwarf  Good point about the sewage worker stuff, lol.
    1
  57.  @igboman2860  I don't think people get upset with diversity. I think people get upset with the conclusions about it. Can we be sure your name change helped you on your resumes? You should research the company you apply to and see if their vision lines up with yours. Even after researching, you really only get a glimpse of the actual company through interviews. Sending a resume isn't exactly a way to express your own "diversity." It's still anonymous from the manager's point of view!
    1
  58.  @igboman2860  Simple. What ultimately decides it is how the interview goes. Not what name you have.
    1
  59. ​ @igboman2860  I may be skipping over your conclusions since you may not be getting interviews for various reasons. In a world where anonymously sending your resume is now the widespread trend to apply for a position, no wonder why it's troublesome to find an interview. People may falsely believe that carefully crafted wording will make the difference. A busy manager only has time to skim the resume. It changes once you can put a face to the name. I am not discrediting your judgments of people being picky. The interview process isn't transparent enough for us to arrive at these conclusions. Sometimes non-qualified people try to sift through technical resumes. It could filter people out of positions for superficial reasons. The structure of how some companies hire is in an "ass-backward" manner.
    1