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

  1.  @andreaszetterstrom7418  Event structure requires thought like anything else. You need to create a rational model to have a comprehensible result.
    3
  2. A user story is a description of the problem in the context of the user. A specification is a description of a proposed solution in the context of the dev. It is the developer story. They are dependent but separate different things. The better the dev's understanding of the user context the better (== faster) the result. In my way-of-working the developer story is a general outline of the solution app or feature expressed as narrative (no implementation details). The most important skill I have developed as a dev is the user interview. Another important skill is the ability to look things up. Both skills are simply the ability to ask the right question. You ask the right question by understanding the context.
    3
  3. Also, I am not a freelancer. I am a software house with a product. I work for myself, not clients.
    3
  4. 🌟 🤩 ⭐ 🌠 💫 ✡ 🌟 Dave squared equals violent agreement! I had to watch twice so I could look up abbreviations. Excellent and enjoyable. Note from a harpist: the conductor is waiting for the orchestra's attention.
    3
  5. My synopsis of yet another very fine video: Strive to write code that is both readable and robust.
    3
  6. Excellent topic choice! Efficiency is the basis for the experiment that is Brown Horse Software. My app is based on a simple network of asynchronous phone networks with data distributed on ranked nodes. The constraints are that it can be both written and maintained by one person and run for pennies. The app itself is a niche app designed for mutability. My Google App Engine cloud footprint is about 500 lines of message switch and network admin code. My monthly cloud bill in development has been .01 usd. Phones are probably the greenest platform around.
    3
  7. Excellent video! What you call froth, I call noise as in signal-to-noise ratio. Most of the differences between languages today is just sugar. I worked on both COBOL and Java internals in the 90's. X86 assembler. (I never wrote a single line of COBOL.) I saw the dawn of both JVMs and .dlls... 😮
    3
  8.  @iamhereblossom1588  Using matrix manipulation in APL to produce a simple summary report required more memory than was available on a small mainframe in the early 1980s. Most of the time was probably spent swapping things in and out of memory. Even COBOL would have been overkill - Easytrieve was sufficient.
    2
  9. Thanks for another very enjoyable video! I prefer to think in terms of code base stability. The term technical debt reminds me of the IBM mainframe term for program crash: abend. As in abnormal end. Your program has abended they would say. It is not wrong but also not very descriptive of the situation: you have confused the processor, it has given up, dumped its memory, and continued on its way. Technical debt just does not describe the escalation of problems that can happen in an unstable system. I have made a career of refactoring code bases into stability. That is most of the task on the 'system' side: programs that run other programs. Most of the effort is in coming to understand what is there and how and where it can be improved.
    2
  10. Very excellent video! Makes me want to work for Spotify.
    2
  11. I think you might be using craft in a very specific way rather than in its more general use to describe something one practices to get better at. Such as 'writing is a craft'. I find the comparison to childhood creations off the point. Software is so ephemeral that it works like a mirror- descriptions of it often illuminate the describer more than the described. So, since my my major was literature, I have always treated software development like any other writing assignment. And that has worked very well.
    2
  12. Internet of things...
    2
  13. ​ @giorgos-4515  Yes, it's true that one can read well-written code like a book but I think the connection goes deeper. Programs consist of executable and data parts: narrative and description, operator and operand. A thread of execution is like a story with a beginning, a middle, and an end. I could go on...
    2
  14. Working on microservices sounds a lot like working on platform software. But I have an address-related story from when I started my second job at a bank services shop.. It was 1980, ATMs had just become legal in Chicago, and my first assignment was to generate an input tape for an outside firm to print address labels. I was given a format to generate with separate fields for number, street name, direction, town, etc. I had to write a parser to produce this from free form 2 line addresses. It was a nightmare. Everyone started panicking because the labels were unusable. So, while I wrote a little label generator for the free form input, the ops manager went out and got some labels. Less than hour later, voila - here are your labels. They had never bothered to ask if we could just print the labels ourselves.
    2
  15. My solution is to avoid complexity by designing for high network latency on the computer that fits in your pocket. I use an App Engine Standard headless web app to pipe async messages to other phones via Firebase. The app runs on simple local file system xml. I use the cloud as a message switch and Google does all the heavy work for pennies a month.
    2
  16. What drives development if not verification? There is a Dijkstra quote about having logically proven that some code is correct, one cannot verify that it works until it is run. The most useful test tool I've used in my career was an in-house record compare program called C12RC that could compare two complicated sequential inputs in amazing ways: late 70s at the Chicago electric utility where I learned programming. In the system and program utility context where I've spent most of my time it is more often the case that you find a test rather than write one. For a Java platform on a device there are conformance test suites for every api. But those tests are just the baseline. You also need to test real applications. But this work was more about optimisation, extending apis, and refactoring out the confusion that manifests itself as fragility or resistance to change than about generating new functionality.
    2
  17.  @berkes  You have just reinforced my point, not its opposite. Interviewing users is a developer's most important skill, not taking instruction from some great product guy. The problem with isolating developers from users is exactly that it focuses the developer's attention on the solution instead of the user's problem.
    2
  18. ​ @ContinuousDelivery  In a browser your UI is in service to your backend. On a phone your backend is in service to your UI. On my phone app this makes everything transparent to the user. Run == test. Instead of swapping out the UI to test, I swapped out the backend from network to file system. Startup time including deployment from the IDE is seconds. The cheapest cpu is on phones.
    2
  19. When did enterprise devs stop being responsible for their work? When I started and worked on mainframes EVERYTHING ran in the middle of the night. If the job that was your responsibility crashed, you got in your car and drove in to fix it because other jobs were waiting and operations had to get all the output printed before a certain time. I became famous among the ops folk for refactoring away problems in programs that crashed. It was a tricky environment because it took a week to process the entire customer base. And lots of things happened on cycles of different lengths. I worked for Chicago's (and suburbs) electric utility. Same thing when I worked for a banking data center. I left that in favor of writing custom PC applications in the mid-80s. So when did things change?
    2
  20.  @markapgar7437  At that point I was doing shrink wrap language and tools in SV... I was always the most productive working with not against operations so best of luck with your efforts!
    2
  21. Great vid! It sounds to me like people often use the word platform when they really mean tool. From someone who has spent a lot of time working on both. A platform is something you stand on that gives you wide access to functionality. A tool is something that customizes that access.
    2
  22. ​ @nijolas.wilson  'You' and 'yourself' is meant to refer to the software, not its author/authors.
    2
  23.  @nijolas.wilson The advantage of software talking to itself becomes very clear once you have visited dependency hell. I pray you remain ignorant of that dark and frightening place.
    2
  24.  @MK-lh3xd  Another astonishing thing about sw engineers is how quick they are to say another engineer's success is because of luck and special circumstances. In reality that is rarely the case.
    2
  25. 15:42 A bit flabbergasted to hear this view of how things were in the 70-90's. It is fantasy. Most businesses ran package software and hired people to maintain it. If you did get the chance to write something from scratch, it became your lifetime responsibility because management was frightened by it. The first question was always "what is everybody else doing?". Not "how can we solve this problem?". I am speaking from first hand experience. I wonder what books gave you such an impression. Open software was a response to package software.
    2
  26. In my experience this is agile vs waterfall or (since I learned programming at a large electric utility and then designed and implemented an ATM system at my next job) an engineering vs a bureaucratic approach.
    2
  27. Thanks for another excellent video! You are singing my tune. The basis of good design is making no assumptions. Always testing for and handling failure is the key to robust code. That is what queues are for...
    2
  28. Gender bias in the software industry, at least in the US, is clearly expressed by the discrepancy in pay as well as expectation.
    2
  29. Why are we struggling to automate tasks that people already struggle to learn? To me AI just seems like a huge waste of resource that spells disaster on more levels than I can count.
    2
  30. Excellent AND mind-blowing! Your explanation skills are unsurpassed. My programmer brain understood it as there being 1 of 2 possible states in a binary digital computer and any number of n possible states in a quantum computer. That is why you need another dimension (matrix) to describe it.
    2
  31.  @BrunoCodeman  Not if you work for yourself.
    2
  32.  @BrunoCodeman  You already defined that term, not me. This is the age of information and the internet where infrastructure is available for pennies. The "means of production" no longer has the same relevance as it did in the industrial age. I am not arguing about means of production. I am talking about employment safety where, yes, workers are not only involved but more highly relevant than means of production. Software is not made in a factory.
    2
  33. My experience with hierarchy: No good deed goes unpunished. I have worked on several good projects. All based on cooperation sans hierarchy.
    2
  34. The suits will never understand that software development is a recursive process. Why would managers support their own elimination?
    2
  35. ​ @FudgeYeahLinusLAN  Hey, I feel you. I experienced the heaven of working for an actual agile software company which turned into complete hell when we were acquired by a large waterfall company.
    2
  36. I started programming in 1977 in assembler on IBM 360/MVS. When I left 3 years later they replaced me with 4 people. I was hired because I got a very high score on the IBM programmer's aptitude test. They taught me assembler in 3 months. It was the last place I worked where there was more than one other woman developer until 2011 when the Norwegian feature phone platform I did the Java integration for was acquired by Nokia. I really enjoyed the interview. I was rather surprised to read the comments, however, which are remarkably unenlightened. The question at hand is how does one attract women to the field, not whether women can do software. As one of those few women who does, I recommend simply pointing out that even though you will probably be paid a good deal less than your white male counterparts, it will still be enough money to pay your horse's board.
    2
  37. Great video! 🌟 🤩 ⭐ 🌠 💫 ✡ 🌟 The sync vs async question dates back at least to my mainframe days in the late 70's/early 80's when IBM was sync and everyone else was async. At least in the land of ATM (banking) networks. Device software is perhaps more obviously event-driven. Nokia had a message-based OS. Rather than going from the abstract to the specific work should proceed from the specific to the abstract. That is how simplicity and optimization is achieved because the architecture will be designed for specific constraints.
    2
  38. I was advised to abandon my first attempt at a career as a harp major at a music conservatory by my top tier teacher (and first female member of The Cleveland Orchestra) not for lack of ability but because I "was interested in too many things".
    2
  39. Count me in. I'm in the choir, too. Your videos are excellent in every way and I get a kind of moral support from how closely your ideas mesh with mine.
    2
  40.  @qj0n  I am only speaking from decades of experience working on compiler, jvm, and platform internals. Perhaps the wikipedia author had a different experience. Please note the first words of my original reply were "I've always heard".
    2
  41.  @ContinuousDelivery  My reference was the Wikipedia article on simula. The reference origin was my Oslo colleagues, not my actual knowledge of the history of software development which is sparse at best. So there may be some national bias at play here. Are you making point that OOP developed over time while FP was created in one go? Is that the fuzzy part?
    2
  42. The future is now. I've implemented an entirely message-based logistics phone app using Firebase messaging. No database just distributed JSON graphs. My data tool is a text editor. It is totally flexible and ridiculously easy to debug. The time it took to implement was due to the complexity and bugs in the Android life cycle, not the data architecture. The only bit in the cloud is an endpoint to pipe the messages to Firebase.
    2
  43. Did the whole concept of command line/runtime flags just get lost at some point? Or have I been working on platforms and tools for too long? By ownership did you mean responsibility? Or possibly silo?
    1
  44.  @Solaar_Punk  Not to mention fixing other people's code.
    1
  45.  @aaronbono4688  I've never had a programming class in my life. My major was English Lit. Even the training course for 370 assembler was an IBM self-directed course. At one point I contemplated getting a degree until a colleague who was going for his Masters (or was it PHD?) in CS told me not to bother. "You already know way more than they do." So I cannot comment on how universities teach CS...
    1
  46.  @aaronbono4688  I think the most important thing for success writing software is the ability and tendency to dive head first into a topic at the drop of a hat and continue diving until you have a grasp of it. I don't know how to teach that.
    1
  47.  @aaronbono4688  Learning how to write for a silicon audience sounds a lot like learning how to write for people.
    1
  48.  @stengrafflarsen  You can define a listener that receives any or all or n of any set of events you wish to implement. There is no limit to how the interactions behave. It depends on the use case. A push client can handle any number of events.
    1
  49. Anyone who has spent time closer to the metal knows that computers are event-driven beasts. Heck, msdos was invoked as an x86 interrupt. And it goes way farther back and deeper than that. XEROX PARC etc.
    1
  50. Excellent video. I wish I had had it to show to all the managers who ignored my warnings about these very things and gave me major flack when I pushed back.
    1