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

  1. There is no safety in employment. No matter how well you perform or how successful your product is, you will get laid off on the whim of some suit. They will offer you a huge retention bonus and then lay off your entire division the next day. Speaking from 47 years experience, the only path to safety is to form your own company.
    55
  2. This reminds me of the MBA at the bank data center who decided he would write the code to generate a business account summary report himself in APL. It brought the mainframe to its knees and ran for hours. I took pity on the auditor tasked with running the report. It took me 10 minutes to rewrite it in the data retrieval scripting language and submit to operations where it ran in just minutes. The MBA was furious but everyone else couldn't thank me enough.
    43
  3. The great thing about a distributed monolith is that you are always talking to yourself.
    24
  4. Excellent stuff!! I learned to code by refactoring all the systems I was put in charge of. Operations loved me as everything I took over stopped having problems.
    20
  5. The ability to ask the right question has earned me the title of "ATM goddess" as well as "the girl who writes code faster than you can sign your name". How did I develop that ability? Majored in English literature. Working on software is like working on any text: research, draft, refinement, repeat. Not to mention: know your audience - both human and machine.
    17
  6. Something I noticed already very early in my career when I worked on a mainframe ATM system was a reluctance to interact with folks in other parts of the business. This astonished me. Rather than consult with the people in their banks, they wanted to ask other data processing centers how things should be implemented. And the answers they got back were insane. So I ignored them and bonded with the people in the banks instead. The gm backed me up and the implementation was a roaring success: first banks to go live by weeks. Since then I have seen this pattern repeated ad infinitum. Perhaps software would be better off if engineers paired with users instead of other engineers.
    16
  7. I was fascinated by how, after your discussion about how software is not a physical product, all of your design examples were physical products. My hesitation at the title of engineer is solely in deference to real engineers because I don't have an engineering degree. It also struck me that the things you mentioned regarding software design are also true of writing. They are both all about organizing information. Thanks for your thoughts.
    15
  8. ❤ Complexity is something that software engineers, scientists, and artists all wrestle with. All of them work by experimentation. It is the nature of creativity in any field. Lovely and very interesting video!
    12
  9. Excellent! Only one thing to add: read lots of code. You can learn piles from both good and bad code and you will get some insight into what it means for code to be readable.
    11
  10. Thanks for another super video. I'm beginning to think that the most important thing to learn as a programmer is how your brain works. My brain does not go to solutions when someone describes a problem, instead it goes into a kind of absorb mode that generates questions. Later, when I pick up a pen, it goes into thinking on paper (graph preferred) to describe, organize, and begin having ideas about the problem. That generates a list of things to explore and research. It is only as this stage progresses that I begin to formulate possible solutions. I always do the easiest things first. Start with something that runs and build from there so you implement what is needed as you need it. Make notes on what is needed as you go. Things you learn on the easy stuff will probably make the hard stuff simpler. Through the entire process I think on paper so I can check things off and remember where I am. I don't think in code, I think on paper - probably due to decades of working in assembler. I do, however, dream in code and rely on sleep to find complicated bugs. When I type code my brain goes into an edit/organize mode quite distinct from the writing with a pen creative mode. Some academic study discovered better exam outcomes for students when taking hand-written notes vs typing on a laptop.
    11
  11. Thanks very much for this exceptional video! It resonates in so many ways. The principles behind agile go back much further than the 20 years. It explains how I as a single person could compete with entire dev departments when I had PC app business in the 80's by working directly with the people in the user department every step of the way. I think the first thing that determines whether an org is truly agile is trust. The second is a sense of humor
    10
  12. ❤ I call my system of working just-in-time development where you only implement what you need right now: start with running code and keep it running. Why just-in-time? Because JIT happens...
    9
  13. Five stars for this video. Excellent discussion on several topics close to my heart. Great to hear backend folks emphasizing user experience and supporting async architecture.
    9
  14. Yes! Yes! I worked for a feature phone platform company that put all of its competitors out of business (before being acquired) by using a similar approach. We cut the development time for a feature phone from a year to 3 months. For the most part, we communicated through code - both locally and remotely.
    9
  15. I've always heard this called regression testing. We had an interesting case at Realia COBOL because the compiler itself was written in COBOL. So you couldn't simply compare outputs, you had to compare the output of the output. I myself worked on the debugger and the compiler frontend person was my best user. When she had a problem I'd be debugging the debugger debugging the compiler compiling the compiler.
    9
  16. Boy was I lucky to learn programming for 3 months as a trainee at an engineering company. Everyone else had taken that route so getting integrated into a team went smooth like baby's feet. Questions were encouraged and everyone was extremely patient helping folks just out of training learn the ropes.
    7
  17. Some of the most beautiful code I've ever seen was uncommented assembler. It was an x86 linker I took over from the author. You could read it like a book, it was so well organized and named. I was the first other person see it and he asked me what I thought. So I quoted a little Keats: "Beauty is truth, truth beauty..."
    7
  18. I scared the sh*t out of people by simply being competent. I would never try to convince anyone because I was always just lucky to survive the sabotage. Until I found a company with highly competent people who were already there. Then I lived happily ever after until msft acquired us.
    7
  19.  @BrunoCodeman  In software development the means of production is the developer. Therefore going to work for yourself is equivalent to seizing the means of production.
    7
  20. Based on the comments, men appear to believe they know more about gender bias than women. Why even bother commenting at all if everything is so wonderfully gender-balanced in the IT community? In my 45 years working as a programmer bias against women has gone from bad to worse. Of course now I also have age working against me. I mostly had better luck with colleagues from other continents than Americans. There is a wide range based on culture. Thank you for raising this topic.
    6
  21. I am all for collaborations of any size. Serial collaboration across time zones can also be highly productive. Mob programming makes lots of sense because it's just like the way they write comedy for TV. What does writing comedy and software have in common? The better and more immediate the feedback is, the better and quicker it's written.
    6
  22. The difference between functional and oo programming is point of view. In functional programming code is data. In oo programming data is code. This from the point of view of someone who's native language is assembler. All points of view are useful in the right context. Arguing that one is better than the other simply misses the point. Thanks for another great thought-provoking video!!
    6
  23. It all about having a culture of trust, respect, and honesty. That is my life experience. Success is a product of cooperation through practice.
    5
  24. You might be interested to know that the deployment technique described is similar to how they deployed the switch running the ATMs on the systems I worked on in the very early 1980s. The switch ran on a mini, I don't remember which, and they would deploy to a second mini and then point the network to it. The company running the switch was Boeing Computer Services in Seattle. So yes, engineering - that was the old Boeing. Cloud computing in 1981: ATMs in Chicago, switch in Seattle.
    5
  25. Constantly changing user requirements are life. Software is automation. The difference between now and history is not that now we are done, but that we are automating different things. The focus of software development has also shifted with hardware capacity constraints going from limited to seemingly limitless. Software development should be about user collaboration. In the same way you need to test the logic of your sw, you need to test the usefulness of the sw. As long ago as the early eighties I have had end-users test my sw. I learned very early in my career that it can be much more productive to be a developer on a team of users than on a team of developers.
    5
  26. For me, software is like Janus, the Roman god of beginnings and endings, with two faces: one looks to the machine, the other looks to the person. The face looking to the machine is an engineer. The face looking to the person is a writer. (Looking to (not at) as in 'in service of'.) The material of software engineering is logic.
    5
  27.  @johnsmith-ro2tw  The MBA left the company. I was never in danger. Sometimes performance can beat politics.
    4
  28. Excellent video! Since early in my career, when people asked about my process, I would just say: "Make something that runs. Keep it running."
    4
  29. ❤❤❤❤❤ I just found out I've been doing BDD for over 40 years. Complexity can also be the product of confusion. I cannot count the number of times I have turned confusion complexity into simple robust code with excellent results. I've spent a large amount of time fixing other people's code: my title was architect but my role was software cleaning lady.
    4
  30. In this case you simply implement an event that is generated when the state is as A is interested in. Then A just registers a listener for that event. NO POLLING! Polling is the opposite of event driven.
    4
  31. The environmental cost of AI crowds out any possible benefit. It is a massive waste of time and resources. This in addition to all the shortcomings mentioned in the video.
    4
  32. Extra great video! If you want to teach your brain to understand concurrency learn to play the pedal harp. Like the piano your hands are playing multiple lines of melody while your feet are supplying the accidentals with pedal changes. I failed as a performer but went on to optimize JVM monitors in the early days of Java when I worked on the Symantec JIT compiler. I wound up having to fix everyones deadly embraces for them. Most programming belongs on a single thread. When I moved from the X86 PC space to embedded at the turn of the century I discovered green threading which is loads easier to deal with than preemptive. You don't need to sync the hardware. Multiple threads are unavoidable in a phone app but can be minimized. In retrospect I think most of the people I've worked with who really understood concurrency were also musicians. Another good way to get comfortable with asynchronous behavior is to write a debugger or two.
    4
  33. I had the incredible luck to learn programming in a shop that practiced something very close to what you describe as Continuous Delivery down to having a group devoted to what is now called DevOps. A decade before I started in the 70s, they worked with IBM to create CICS and maintained an in-house version called Pronto. I learned to write code for distributed systems by fixing production bugs and rewriting parts that suffered from the entropy of earlier misguided fixes. The data was distributed over time, not space. We were the electric utility for Chicago and surrounding suburbs. The customer dataset was so large that it took a week of nightly runs to process the entire thing and everything happened in cycles of various lengths. Anyway, I just wanted to point out that CD is a great but not necessarily new idea.
    4
  34. On the subject of shiny things: back in the early 80's when I was working in banking writing ATM networks an MBA decided to program a weekly business accounts summary in APL. He showed the auditor how to run the program which took hours to run and brought the mainframe to its knees. I could not watch this so I wrote the report in a scripting language and gave it to operations to run every week. The auditor was eternally grateful. The MBA took me across the hall into the bank vault and balled me out for being unprofessional.
    4
  35. I am against ignoring "flakey" tests. I can tell you a horror story about what it is like to have 3 days to fix a timing problem that people had ignored for 3 months. A "flakey" test can be a harbinger. I always investigate them. But I am also against a backlog with more than zero items. So there's that.
    4
  36.  @BrunoCodeman  All of those things have nothing to do with controlling the safety of my employment. If I could own Dell Computers to the point of controlling my employer, I would not require employment. My assets are in my skillset not my bank account.
    4
  37. Wow! Too many things to chime in on. Great talk! Count me in as a grumpy old gal who also agrees with everything. I was an English major lucky enough to start programming in the 70's when an interview consisted of the IBM programmer aptitude test. Then you had to pass all the exams during the first three months of working through the IBM self-taught assembler course. I remember asking a colleague during training about this language called assembler. I had heard of COBOL and Fortran but not assembler. Will it be useful to learn? Don't worry about that, he replied. It will definitely be useful.
    4
  38. When I first heard the term test driven development my initial thought was OK but then don't I also need to write a test to test the test code? In other words,, why would the test be more trustworthy than the code I'm writing? Then I saw one of your videos and realized that the important part is not the test but the ability to test immediately - that is, having a way to test the code before you write it. So your test is not so much a test to prove correctness as a running context to providest immediate feedback. I cannot imagine writing code before you have a way to run/test it. I have spent most of my time on platform internals and prefer to find a test rather than write one both to avoid programmer bias and exercise other people's code. Now that I have returned to app development (UX and everything) implementation order by design takes care of providing the test context for coding. Then I let Google do their automated approval testing on my Android app for me: less code to maintain. I already do a lot of thinking and organizing on paper before coding - maybe because I started and have done lots of work in assembler. Maybe because I was an English major.
    4
  39. Back in the early days of Java as a member of the orginally 3 person and eventually 4 person Symantec JIT compiler team, a big part of my role was optimizing JVM monitors and garbage collection to shame Sun into improving their PC x86 implementation. The interpreter worked fine on Solaris so why bother with how it runs on PCs? Symantec had pivoted their IDE from C++ to Java and needed the performance to get people on board with Java. C++ was made impossible by Microsoft making it a moving target with library releases. The huge improvement the JVM promised for us was not only write once run on any but also eliminating Microsoft from the picture. The JIT compiler became the standard for the Classic JVM. The eventual 4th member of the JIT team is now Director of SW Development at Oracle.
    4
  40. 🌟 🌟 🌟 🌟 🌟 🤩
    3
  41. ​   I was the first person to see their code. It was not the first code I had seen. Apologies for the confusion.
    3
  42. Welcome! Meetings are an art that few ever master. At the job of my dreams we had a weekly meeting where any topic requiring more than 90 seconds was addressed in another meeting that you used your 90 seconds to organize. There were no managers in that company and everyone managed just fine.
    3
  43. My immediate reaction was that you should get rid of that product guy and talk to actual users. In my experience they don't want lots of features as much as they want features that work well and the more direct your contact is with that user the better your feedback and chance of success. An additional thought is that I have always found success by treating operations as another set of users. In fact, it has made for not only a project's salvation but also for a huge success even in the face of sabotage from people above me in the development hierarchy.
    3
  44. I should also mention that my way-of-working has always been what has become known as agile. It is because my approach to writing software is the same as any writing assignment: Do research: analyze the audience, topic, and context to come up with an approach. Then revise until done. Writing is revision. Going back to research as needed- this is a recursive process.
    3
  45. You cannot compare software of the 90's and 2000's without a single mention of the differences in hardware. At the beginning of the 90's everyone was running 8 bit software on 16 bit machines. So we converted to 16 bit segmented architecture from 8 bit real mode and by the time we had done that the chips had moved to 32 bit and back to real mode where it has stayed. Not to mention the rise of the web and the jvm mid-decade with the rise of the internet. Is it ironic that the facility invented to distribute data for safety is nearly entirely used to centralize data? And that centralization being responsible for so many of the woes associated with the internet. I would not say things were easier or harder - just different.
    3
  46. The most important and completely impossible to test for components of excellent software are curiosity, imagination, and creativity.
    3
  47. It's interesting to know how you would use AI for software development but I have far more interest in discussing whether we should use AI. Cui bono? Are the broligarchs not rich enough yet? Is data processing on steroids really worth the explosion in carbon footprint? Just because you can do something, does that mean you should do it?
    3
  48. Thanks for this excellent and dry conversation. Looking forward to those future contributions! After 46 years I can safely say that the most important and valuable skill I've learned as a software engineer is asking questions.
    3
  49. I have been thinking about the edges of design Dave has mentioned in several videos and how they are to be avoided. My experience is the opposite: that the surest way to create value is to embrace the edges and make that your starting point. Because that is where the user is so you can constantly test for value as well as function. I think the examples in this video illustrate my point.
    3
  50. Thanks for yet another interesting, informative, and thought-provoking video. It made me think about my experience with teams and experts. The best and most successful teams I've worked on were small and everyone was an expert. If there was something outside our expertise we learned it or added another person as needed. I've also been an expert passed around to other teams. My experience with that was no good deed goes unpunished. It was also a path to burnout: the product would ship and everyone goes on vacation except the expert who is needed for some other project. I usually felt more like a software cleaning lady than an expert.
    3