13 karma · joined May 3, 2017
The problem is there are too many things that are interesting and desirable to learn and not enough time for everything.
I recently had a similar conversation of a younger person who wanted to learn development and wondered on what to focus on to start. You need some way to filter the very broad scope of possibilities to something narrow enough to begin a focus. One possibility is to decide on a platform. Do you prefer to work on web apps, desktop apps, back-end, DB, mobile, etc.? That selection will help to narrow down which tech may be better suited. Another option is to pick an open-source project that you use and like. You could then learn that tech stack and begin to contribute to it, thus getting your efforts and new knowledge documented.
There are also a wide variety of nibs to choose from. They can vary in material, widths, firmness, and how they flow across different papers. If you mostly like a nib, but it's still not quite right for you, you can have a nibmeister tune it more to your liking.
Some who write a great deal are not comfortable with the smaller quantity of ink in a cartridge converter or the shorter refill cartridges. I have used pens with these and still have some, but prefer a piston filler for the usually larger quantity of ink it can hold. It is even better (for me) when I can also look at it and see how much ink remains. But, if you have those and then rarely use it, ink can dry in the feed. In that case, something with an ink cut-off, like the Pilot Custom 823 Amber, may let the majority of ink remain even if not used. That pen is one of my favorites.
You can try any pen as a starter. But, if you don't like it, remember the preferences. That pen may not suit you, but another may be a perfect fit. Welcome to the hunt for the perfect pen.
Often, decomposition is based on areas of domain or functionality. There are some downsides to doing it this way. The method in the book proposes it be based on areas of volatility instead. As an example, imagine writing a piece of software for FedEx shipping. What would change to use that same software for UPS instead? That may identify some areas of volatility. If you can plan that something might change, you can limit the ripple effect of those changes in future. Just an example of one benefit of doing it this way. The book explains some of how to approach designing this way.
Another point: Architecture is not just about designing the software. It is also designing the project to build that software. This involves things like critical paths, staffing, risk management, etc. Understanding these is important if you want to be able to deliver on time and on budget.