51–60 of 258 posts
2 - Write the simplest code to fulfill this specification;
3 - Improve on what you wrote so it will express better exactly the specification you have so far.
Earlier quoted context omitted.
Can you explain this a little more in your own words, I've tried to read through TDD and talked with co workers but never actually seen this in the wild. How do you go about planning your tests / separation of concerns. As in do you only write tests for your service layer? I find I'd be wasting time to write it at the controller level/route level. What about the DML schema? Personally I always start at the database l…
Here's how I look at it.. when writing code, you need to run it to try it. Often people refresh the browser or re-run their CLI program until their feature is finished. But if you think about it, every "refresh to check if it works" is just a manual test. TDD is just making that manual test automated. 1. Write that test (that you'd anyway have to run manually) 2. Write code until test pass 3. Repeat 1 until done. Cod…
It is really hard to know what other people want or what they mean. If you can really understand what someone wants, perhaps you can avoid write 50% of a system you initially imagined.
Don't design your software for future features you might need. Design it to be easy to change. This means it has to be decoupled and simple. The trick is to make the software decoupled without making it complex. Adding layers and interfaces and abstractions is the easy way to achieve loose coupling, but it also adds complexity. Making software that's simple while still being easy to change is much harder than making…
> The trick is to make the software decoupled without making it complex Any insights into how to do exactly this? Any rules of thumb or guidelines? Also what is not considered complex to some adds a cognitive burden to others.
I think the sense is mostly developed not by successful designs but by mistakes and the subsequent refactorings.
The only “simple” advice I have is that in FP the simple and decoupled seems to happen without added work, while in OO it’s quite a cognitive overhead to avoid tangling things up. So my only insight is perhaps “make everything simple functions and shy away from state whenever possible”.
If there is an actual customer, try to get the scale of users/data the system is expecting. A system handling 1/1k/10M things every day will be quite different and need different solutions. Problems arise when people reach for the Cool Tools and start building Webscale things that can handle 100M operations every second. ...but the customer only needs the system to handle 4 users who type in everything crap by hand.…
How much time do you spend "making it pretty" after you've got it functionally working? Interested to hear your experiences on that. For a long time we would "pretty it up at the end", in one of my coworkers words, which lead to a ton of horrible UX decisions early on that required major legwork later. We switched to doing ux-driven development from the start and it's saved us a ton of time and saved ourselves from p…
It depends on the customer and project which parts I focus on making "pretty". If it's a data-intensive thing, I might spend time optimising the protocol, compression and making the data pipeline robust. For a web app I'll spend more time making it more usable by streamlining the most relevant flows (which I know of since the client has been testing the (M)VP already).
Earlier quoted context omitted.
Also: have a framework in place, which supports worry-free refactoring. Comprehensive Unit/Integration tests, a robust type-system, pick whatever suits your style. It's a lot easier to refactor stuff when you don't have to worry about breaking something hard to debug with a big code change.
Unit tests are absolutely fantastic during refactoring. I once had to rewrite a piece of code where nobody really knew what it did or what it had to do, and the original author just made some guesses about the intention. I started out by writing unit tests for everything, which became my handhold and documentation for what the system originally did. Then I started reorganising the code into a more structured and more…
Great book BTW, should be on a top10 must read list for software developers. (#1 will always be Peopleware[2])
[1] https://www.goodreads.com/book/show/44919.Working_Effectivel... [2] https://www.goodreads.com/book/show/67825.Peopleware
Earlier quoted context omitted.
> The trick is to make the software decoupled without making it complex Any insights into how to do exactly this? Any rules of thumb or guidelines? Also what is not considered complex to some adds a cognitive burden to others.
No, I can’t think of any simple guidelines. It’s a tingling sense you get after 10-20 years of doing it that says “I should probably make this simpler and direct” or “I should probably make this more general/layered”. I think the sense is mostly developed not by successful designs but by mistakes and the subsequent refactorings. The only “simple” advice I have is that in FP the simple and decoupled seems to happen wi…
The mid-career developer knows this from experience and sticks to the minimum necessary to meet the requirements. Fast and efficient in the short term.
The senior developer mostly agrees with that but also knows that there is nothing new under the sun and all software ideas repeat. So from experience they can selectively pick the additional implementation work to be done ahead of time because it'll save a lot later even if it's not needed yet.
As an aside, this is one of the many reasons why I interview based on discussing past projects and don't care for algorithm puzzles. Unless I specifically need an entry-level developer, I'd prefer to have the person who has written a few silly (in hindsight) complex frameworks and has painted themselves into a corner a few times with overly simplistic initial implementations. That's the person I know I can leave alone and they'll make sane decisions without any supervision. The algorithm puzzle jockey, not so much.