soonnow (u/soonnow) - Readit News

soonnow commented on German Naming Convention chrisdone.com/posts/germa... · Posted by u/thunderbong

Indeed.

The problem with long var names is that formulas become unreadable and function names take away horizontal real estate for their args.

There are so many ways out to make it shorter yet readable.

- idx is often used as index.

- An event handler can start with On.

- Simply take the first 3 or 4 letters of every word. simpToReadVar

- keyISR Keyboard Interrupt Service Routine

- fName file name

soonnow · a year ago

I just want to point out you are saving 3 characters on the last one while making it a fair bit harder to understand. fileName is perfectly fine. fName could be firstName, fileName, finalName, foundName...

soonnow commented on When are SSDs slow? cedardb.com/blog/ssd_late... · Posted by u/eatonphil

soonnow · 2 years ago

We used a small embedded db in our desktop product only for durability and SQL semantics. After we got multiple database corruptions we switched to a small file based store written in Java with simple DB semantics.

Looking carefully at what happens when data is lost we found that it's basically all recoverable.

This lead to an amazing performance, as data is flushed only when necessary. We flush only every 10 seconds now or when the write through cache is full.

My lesson learned from that is to carefully think about the actual requirements when it comes to transactions and having loose constraints may be the quickest way to speed up performance.

For many applications even a second or two of lost data may not be a big issue.

soonnow commented on Fitch downgrades U.S. after debt limit stalemate politico.com/news/2023/08... · Posted by u/koolba

avidphantasm · 3 years ago

This may be a chink in the armor, but so long as the USD still the dominant reserve currency and oil is mostly traded in dollars, does anyone care what Fitch thinks? Now there may be some movement away from USD for both of these uses, but I think this has more to do with geopolitics than what Fitch thinks or the petulance of the GOP.

soonnow · 3 years ago

I think AI is going to be the driving force behind technological innovation for at least the next 10 years. And the US has that market cornered expecially with the CHIPS act. I think that will drive growth in the US and be more relevant than the reserve currency status.

soonnow commented on Dysregulation of hypothalamic gene expression by soybean oil in mice (2020) universityofcalifornia.ed... · Posted by u/haltingproblem

soonnow · 3 years ago

Can I just say that aside from the presented facts. I really liked the reporting. It clearly explained what the study showed and what the studies didn't show.

I think science reporting should be more like that. It's ok to have an article that says well we found a link but we are not clear yet on what's the exact cause, but we know what's not the cause

Aside from the clickbait-y headline of course.

soonnow commented on Russian paramilitary chief says his forces will turn around nytimes.com/live/2023/06/... · Posted by u/veer

ranger207 · 3 years ago

> Second observation was that the regime did not exist in the moment: with few notable exceptions, we have not even seen faces of anyone from national security council. Some local actions of the governors, fortification of Moscow, pathetic speech of Putin in the morning and that’s it. The weakness of it in the face of a violent force was exposed.

This is, in my experience, actually a good indication that the event was truly a surprise to the Russian government. Their media apparatus is very good at having a cohesive narrative and lots of talking points in place before planned information operations, and they're not typically great at responding to events on the ground as they unfold, usually needing a couple of days to assemble a media campaign in response to unexpected events. The lack of any coordinated information response is a tell that the Russian government didn't anticipate this whole shebang.

soonnow · 3 years ago

Anders Puck Nielsen talks about this in his video https://www.youtube.com/watch?v=jabKKr3pstU According to him the hallmarks of a Russian Flag operation are

1. Bad production quality and a clear message

2. Intense media coverage in Russia

3. Positive message about the Russian state

Literally none of these points were apparent here. It shows a weak Russian state, was covered only as so far as necessary and what the message would be was completely unclear. Don't hire mercenaries?

soonnow commented on Ask HN: What are some of the most elegant codebases in your favorite language? · Posted by u/debanjan16

winrid · 3 years ago

Have you tried C#? It looks a lot nicer to work with than Java.

soonnow · 3 years ago

I'm using C# and Java professionally. I've been using for a long time while I'm newish on C#. Also I'm on a older version of .net vs. a modern Java. Honestly to me the language doesn't feel that great. It always feels sluggish, to work with, like I'm fighting against the language. And then there is the ecosystem, Spring Boot is just such a breeze to get a web app running with all the integrations you could ever want being just there. Add in Lombok and Apache commons and it's a real pleasure to develop in Java for me.

soonnow commented on Ask HN: What are some of the most elegant codebases in your favorite language? · Posted by u/debanjan16

NBJack · 3 years ago

Try JetBrains Rider, and be sure you are using a recent flavor of dotnet. When I migrated past 4.x to 6 of the .Net ecosystem, it dramatically improved my ability to work and deploy in C# with their rather delightful build system.

For example, in the Monogame game library, you can build a self contained binary for Windows, Linux or MacOSX nearly effortlessly with just a single command line.

soonnow · 3 years ago

But these executables are quite huge, are they not?

soonnow commented on Banks, crypto lobby clash with lawmakers over Fed digital dollar politico.com/news/2022/08... · Posted by u/JumpCrisscross

benj111 · 4 years ago

How does a 'digital dollar' differ from the dollar in my bank account?

I can send it electronically. I can exchange it for 'real' dollars, etc.

Is this people not getting crypto jumping on the band waggon, a dollar in the banking system but stripped of all the protections, or what?

soonnow · 4 years ago

It offers the benefits of bitcoin (as a money transfer mechanism) without it's downsides.

For example it reduces the costs of international transfers as well as the ease of doing them. Swift transfers are not fun and easy to get wrong and fairly expensive.

And with Bitcoin you'd end up with the currency exchange twice and then the gas or transfer fees.

Also payment in bitcoin fluctuates so you'd have to write the invoices in BTC, which is not that useful. But companies writing invoices in USD are common enough.

soonnow commented on Ask HN: Is there a way to get Agile right? · Posted by u/yakytaky

Jtsummers · 4 years ago

> So, my question: Is there a way to get Agile right? or are we doomed to fail in the same ways that has been described by countless articles discussing the downfalls of Agile?

Yes. Don't be dogmatic. Pick an initial set of processes/practices that match more or less what you already do, want to do (based on a reasonable belief of utility and practicality), or have done (with success) in the past. As you move forward, periodically reexamine what you do and change when something isn't working well (in Scrum this is the Sprint retrospective, which seems to be the first thing cut from every Scrum-derived process I've ever been part of or near to "save time"). Experiment not just with your code and systems, but with your processes and organizational structures themselves. If you only apply things like the ideas of Extreme Programming to your programs, you're only doing half (actually less) of what Agile aims for.

Sterman in his Business Dynamics book has a nice set of diagrams starting on page 15, talking about feedback loops/systems for learning.

Attempting to draw them as ASCII art, not that skilled at this:

Simplest feedback model:

         Real world
         ^      \
        /        \
       /          v
   Decisions<--Information feedback

This is a very common thing, people make a decision, try it, get info, and make new decisions. What they don't do is extend this feedback to their decision making model. He extends this model on page 16 with:

         Real world
         ^      \
        /        \
       /          v
   Decisions<--Information feedback
      ^
       \
        \
     Strategy, Structure,
       Decision Rules
           ^
            \
             \
          Mental Models
            of Real World

Again, note that the feedback does not go back to the mental models which feed into the decision making strategies and, ultimately, the decisions. This is the dogmatic approach to any process. You select it, and you run it regardless of its real applicability or utility but based on a belief that you don't update (because it's dogmatic). Doesn't matter if this is Agile (big-A) or big design up front (BDUF) or anything else, if you don't reconsider your models then you will not be agile, you will be stuck. This doesn't mean things won't work, you may have settled into a local optimum (on accident or on purpose). Maybe things are done this way because they've always been done this way, but 30 years ago someone did think about the business and selected something that worked (deliberately) and things haven't changed much so it happens to still work well. But once it fails, you have no deliberate way of adapting to the new reality (which is a key to being agile, responsiveness).

The final model he shows on page 19 brings that feedback to not just the decisions but also the models (this is the hard one to put into ASCII art):

         Real world
         ^        \
        /          \
       /            v
   Decisions<----Information feedback
      ^                       ^|
      |                       ||
      |                       |v
  Strategy, Structure,<----Mental Models
    Decision Rules         of Real World

This, to me, is the critical thing to agility and if you focus just on the manifesto and not the Agile Industrial Complex (and fuck SAFe and others like them), you will see that this is present (though less explicitly). Paying attention to feedback, trying new things, being adaptive. That is the essence of agility and Agility.

=======================

Regarding using a shared spread sheet or something else for managing your work, that's all about scale. A 4-person team can use a spreadsheet for status management, it may not be the best, but it will totally work. Scale up to 4 teams, each with 10+ people, possibly geographically separated, and you'll need something else. But take one 4-person team or 4-teams that are all located in the same space, you could manage your status with sticky notes on a whiteboard and probably be as successful as with the spreadsheet or the fanciest project management software (and maybe more successful in some cases because of the relative ease and flexibility sticky notes on a whiteboard afford compared to the fixed, or more fixed, workflows of most PM systems). What you record, how often you review and consider things, those are going to be more critical.

soonnow · 4 years ago

Your comment is fascinating especially since I've been thinking about digital transformation and what it means for businesses a lot, lately.

I would like to make one point that I would highly recommend in respect to a lot of people unhappy with Agile methodologies.

I suggest picking a method, let's say Scrum and really implementing it as recommended. Get a coach if necessary. Try to experience it first before making changes. I think for example the self organizing team has to be experienced rather than read.

Only once you have done it, by the book, start making changes and improve the process.

Don't fall into the trap of reading about Scrum, thinking well I don't need retrospectives they are dumb and do your roll your own thing.

Understand what Agile is, rather than follow some cargo cult interpretation.

This will lead to dark agile, or agile in name only, where you do waterfall but with daily standups.

Which I think explains a lot of the unhappiness people experience with Scrum.

soonnow commented on Ask HN: Is there a way to get Agile right? · Posted by u/yakytaky

niatrecsa · 4 years ago

As someone who has worked in 5 different companies using some form of Agile, I have the following take on this (below). I know you said you're not strictly a development team, but that's where my experience is and the comments below are focussed. That said hopefully some of the points are transferable to your domain.

- Agile is about flexibility, but it can* come with a much bigger price tag if you don't do most of your analysis/design up front for big/technical projects. *Sometimes not always. More on this below.

- It's great having conversations with product owners and business representatives at various times as you progress to other features, but you can't have multiple developers going back and forth for this (as you loose continuity) and if you choose your lead developer or solution architect (if you have one), then they'll spend more time on admin than on actually designing and building things. Therefore it's good to have a business analyst or dev manager help do most of this, with the option for your tech guys to get some face time with product owners if they want/need it.

- I found that none of the business analysts charged with leading/facilitating the Agile requirement gathering really knew how to write good epics / user stories where I worked, and this can make life difficult / waste lots of time during refinement sessions and during development.

- The biggest challenge I found with Agile previously is how to incorporate design tasks (more on this below).

- Some of the business analysts, dev managers, project managers, portfolio managers that I worked with thought that once all the epics and stories were defined we'd just be able to build everything with zero design. Er, no. The lack of a definite 'design phase' like in waterfall doesn't mean no design is required, it just means that your design execution is more flexible and incremental if need be. You still should go through the design process for your separate features (as they get prioritised) because a) Like TDD for units of code, it forces you to think about the gotchas/edge cases/touch points/cross cutting concerns BEFORE you implement something. b) You have the design to refer to in follow up discussions with product owners / BAs / dev managers and your development team which could consist of several developers.

- By design above I mean a design document/wiki page that covers conceptual, logical, and physical aspects of the solution that will be built. The design might also include and overview of discounted designs initially considered but then not chosen. You want your conceptual/high level design section to be just that, with all the really tech stuff in your logical design section e.g. most your UML stuff and other tech points. But back on Agile, by design I ALSO mean Spikes and Proof of Concepts that you sometimes need to do to validate design assumptions.

- Even with an 'Agile' approach being dictated from above, you might still decide / realise that you need a waterfall approach of sorts, at least initially for the analysis and design (or enough of the design to de-risk things). For example, in massive or extremely technical projects if you don't consider the full requirements or full design up front, then you can have these incredible costs of re-work. E.g. If features 1 and 2 need to be re-written because their implementation is not compatible with features 5 and 6 which were always needed, but were just further down the backlog and not considered in the initial design work.

- This leads me to what I see as the the delayed cost and increased cost of Agile, for large projects with set business requirements. By that I mean again, if you have a large/very technical project with clear defined goals (example in next point), then you probably want to do your full design up front or at least 80%-90% of it. Definitely all of your conceptual design and most of your logical/detailed design and some physical design. Why? Well you don't have to, you can be fully Agile and do just in time / incremental design as you build new features, but the business and your tech leaders need to be told that this can come as a BIG cost down the line. As mentioned in my previous point, you could deliver certain features first but then discover you need to substantially re-write them at a later point because the design didn't factor in those features 5 and 6, that turn out to be just as important. If your business and tech owners aren't aware of this risk when they are sold on the Agile approach then I guarantee they'll be fairly pissed with you when you say you need to re-implement features 1 and 2 and they need to swallow the cost/delay of doing so.

- By large projects with set business requirements, think an entire ecommerce platform that is currently live but total spaghetti code that the business knows needs to be replaced due to slow / costly changes, or other technical risks. E.g. You know you have a search feature, product page feature, category page feature, basket feature, checkout feature, authentication/membership feature, fulfilment feature that ALL need completion.

- So how do you do Agile and Solution Design for large/complicated projects? I like this approach:

a) Your BA defines the high level features in the user story language ('as a', 'I want', 'so that') if the features at a high level lend themselves to this format, but if not, some general high level description of the features.

b) Your BA then starts building the backlog by defining the actual User Stories for certain features, in whichever priority they are likely to be built/released in. They interact mostly with the product owner, but ideally bring them along to at least some of the refinement sessions with the dev team.

c) You raise a technical story for Your Solution Architect / Tech Lead to do First Draft of the Conceptual/High Level design for feature A or features A-E if you want to de-risk things a bit more. You can have another story for First Draft of Logical/Detailed design too.

d) Your SA / Tech Lead then starts on the design under the relevant stories, but also raises Spikes, Proof of Concepts, and other composite design stories within your technical backlog, to cover off questions/unknowns that need to be answered for enough of the solution to be done. This is where you can get your dev team involved in the design process, by ticking off some of those technical stories. For example, you might as part of your design need to consider Capacity and Performance but decide to divvy up the work, and get the devs to flesh out that part of the design. Or you might decide a Spike is needed to determine if X is needed or not. Or you might want to prove a facet of your solution with a bit of POC work.

e) As both b-d progress above, your team will be able to start estimating some of the backlog being produced by the BA. You'll reach a point where you have both enough of the business requirements gathered, documented as User Stories or Technical Stories, and estimated.

f) Then you can start building the initial / highest priority features, while the BA and SA continue to progress with b) and c) respectively. You can do this because they've had a head start and your team has enough backlog & design to get started on development, while the BA and SA then try and keep ahead of the curve with the remaining backlog and design work.

- Part of the problem is that even with Agile development, certain businesses will want an up front estimate for a large project for costing purposes and budget sign off. The key to avoiding issues is honesty. Rather than giving some finger in the air estimate, you need to explain that until the precise requirements are known, solution devised, and backlog estimated, you can't give a precise estimate. Try to ask them for at least some of the concrete requirements and for a week or two for your SA / Tech Lead to give an initial estimate. Let them know that early on at best you can probably give only a +/-30% or +/-40% estimate.

- Most of the points above focus on Agile with big projects, but if you have a well established product / platform, and are making smaller feature changes gradually over time, then Agile preparation and development is much simpler too.

- So again, finally, honesty, honesty, honesty, is a big part of success. Your BA's, PM's, Dev Managers, SA's, Tech Leads, Dev's, all need to learn to be comfortable saying: 'I don't know the answer/estimate to that right now, but if you can give me x information and y days then I can get you an answer, or bring you much closer to having an answer.' and 'Because we're taking this approach of developing and delivering features A and B sooner with an Agile approach, it means that we might need to re-work some of the implementation at a later time when we consider and design features C, D and E.' and (as can happen with waterfall).. 'Unfortunately we underestimated X, and need Y amount of time to complete it. We've learnt Z, and this will help us avoid this situation in future.'. Good luck!

soonnow · 4 years ago

> Rather than giving some finger in the air estimate, you need to explain that until the precise requirements are known, solution devised, and backlog estimated, you can't give a precise estimate

You make a lot of good points but I disagree with this one. I understand the need for business to know how much a project will cost, but I don't think there is any other way than finger in the air. Or rather looking at a project of similar scope and going from there.

The core of agile, for businesses, in my opinion is to deliver business value in the shortest amount of time. Changing requirements are not a bug but a feature of Agile. But you can't estimate for the unknown.

Let's say you are building an app for a bank that allows customers to leave comments on merchants as an option, three menus down. Turns out your customers love that feature and the bank decides to promote that feature.

This business agility is at the core of digital transformation and it should not be discussed away as not being part of the original requirements. Rather it should be embraced.

But you can't estimate the unknown. And I have in my life never seen a project that didn't have wild changes in requirements along the way.

So in my opinion you may as well throw out a number based on experience. Deep estimation based on Excel sheets and task completion times are not gonna improve on the result.