21–30 of 52 posts
Earlier quoted context omitted.
I've been considering moving away from azure postgres to azure SQL server coz azure postgres runs at a snails pace.
Azure is ridiculously slow unless you ask for decent IOs performance but then it's ridiculously expensive.
Earlier quoted context omitted.
Time to change jobs then.
HN resorts to the "just quit your job lol" far too easily. people are in all sorts of different situations. you don't know if they are struggling to find work and this is the one shot they have been given. you don't know if they are in extreme demand and get paid well to fix bad situations like this. you just don't know. and telling people to blithely change jobs when they can't or don't want to isn't helpful
> Delete the project from your development machine, clone the source code and set it up from scratch. Very good advice. This was obviously never done in my org, leading to newcomers (me included) wasting weeks to get started on some projects. Once it was fixed, a newcomer can start working in an hour.
actually having a newcomer install everything and fix the documentation while doing it is even a better option, cloning has some of the dependencies but other might have been installed by the developer for example global packages for NPM or Python, setting of system wide environment variables etc.
Though I once inherited a large enterprise code base that I had to study and build a dev environment for pretty much all by myself. I had maybe 2 calls with the original team and a couple of emails but was mostly by myself just figuring it out. It was a pretty incredible experience and taught me a tonne about how the system worked and was put together. This helped immensely when we spun up a team to work on it. So, I get where this article is coming from due to that experience, but didn't think to do this kind of stuff on purpose.
Who has time for this? I've always been on under resourced projects where every hour had to be signed off. Everything is a rush and quality is required but never budgeted for.
It's a bit of an argument for "less haste, more speed".
As an example, I've always found with CI (continuous integration) servers that setting them up on day 1 of a project takes almost no time, but trying to set them up 3 months (or later) into the project seems to require a lot of time. Once a CI server is set up, it invariably improves both quality and productivity significantly, they start yielding dividends on their time investment very quickly.
If management claims they can't afford the relatively small amount of time required to set up a CI server, then I would argue that the lack of time only strengthens the need to have it done sooner to enable the project to move faster.
For onboarding documentation, finding random time may be hard, but it's almost free if it's done by a new member as they join a team. As they get their environment up and running, they just need to document the steps as they went along. Make sure it's committed to the same source control repository, readme.md seems to work well for this. It's fine if it's initially very simple, just an unformatted list of steps in plain text is a great start.
If someone is adding new technology stacks which would would affect the onboarding document, they should quickly add it at that moment, while possibly improving it a little by adding a little formatting. Future new team members should also be encouraged to improve the documentation based on their onboarding experience. Over time the document becomes quite refined and easy to keep upto date.
That doesn't address all their points, but it's a start and I hope it's helpfull.
> Try to add support for a completely different database. Details of your current database that have leaked into your data layer abstractions will soon become obvious Well, details of Postgres have leaked into my database queries and schemas, but it was a conscious decision to use Postgres and its features. Sure, it seems nice to be able to swap one database for another, but you lose out on a lot of what a database c…
Yeah I don’t get that obsession with “pluggable databases”. Abstractions have a real cost, and they typically complicate a lot: I would advice to just make sure you centralize the access to your database in a single module / class / whatever, but other than that, swapping out databases seems like a non-goal to me. How often do people really migrate to a different database? Even when doing so, migrating the existing d…
On the other side, I worked on a web app that supported multiple db vendors, we did the classic DAO pattern which worked well. You still get to use custom SQL for each database if you need to.
We tried an ORM at one point which worked out well. It was the same web app and we moved moved some DAO code to the Java Persistence API. We could then build the data access code and include it into our desktop (Mac Windows) and plug it in to a local DB (Derby).
In that case, once JPA was working, the pluggable database was allowing us to save on development costs.
> Try to add support for a completely different database. Details of your current database that have leaked into your data layer abstractions will soon become obvious Well, details of Postgres have leaked into my database queries and schemas, but it was a conscious decision to use Postgres and its features. Sure, it seems nice to be able to swap one database for another, but you lose out on a lot of what a database c…
Yeah I don’t get that obsession with “pluggable databases”. Abstractions have a real cost, and they typically complicate a lot: I would advice to just make sure you centralize the access to your database in a single module / class / whatever, but other than that, swapping out databases seems like a non-goal to me. How often do people really migrate to a different database? Even when doing so, migrating the existing d…
I tend to agree, as long as the database you’re using is of the free and open source type so it’s a low-risk dependency.
The “pluggability principle” holds more strongly for higher-risk dependencies, IMHO. For example, if you’re working in an online environment and you can’t readily integrate a new payment processor or messaging service or whatever, your existing dependency starts to look like a single point of failure that is not under your control. Some careful abstraction of the essential features and avoiding dependencies on the peculiarities of any specific platform can be a valuable safety blanket if your external dependency catches fire one day.
I wrote the code, and got it working in about 2 months. It did everything in the spec, and the customer (Russ) loved what we had, but it turned out (of course) there were many things missed in the spec.
A week or two later, we worked out a deal for all of their power plants, provided I would work with Russ to make sure it did everything they wanted... it would take about a year, in the end. Russ taught me everything I needed to know about users and how they think, in a direct and very effective manner.
He was the assistant plant manager, so he would pull a random person into the office, and say to them "I know you're not a computer person, I want to you to do X,Y,Z... but don't worry... if anything goes wrong, it's not your fault... it's Mike's fault (Russ points at Me). He then tells me to just watch... It took exactly 1 minute to learn the first lesson... there should always be "Press F1 for Help" somewhere on the screen.
It was a very instructive and productive year. I've carried those lessons from his forcing function with me for decades. I love telling the story, thanks for listening.
Who has time for this? I've always been on under resourced projects where every hour had to be signed off. Everything is a rush and quality is required but never budgeted for.
To borrow a line, if you think quality is expensive, try cutting corners.
> Try to add support for a completely different database. Details of your current database that have leaked into your data layer abstractions will soon become obvious Well, details of Postgres have leaked into my database queries and schemas, but it was a conscious decision to use Postgres and its features. Sure, it seems nice to be able to swap one database for another, but you lose out on a lot of what a database c…
Yeah I don’t get that obsession with “pluggable databases”. Abstractions have a real cost, and they typically complicate a lot: I would advice to just make sure you centralize the access to your database in a single module / class / whatever, but other than that, swapping out databases seems like a non-goal to me. How often do people really migrate to a different database? Even when doing so, migrating the existing d…
If they already have an Oracle license, or a MS-SQL DBA around, you either say goodbye to Postgres or give the contract to your competitor.
Long ago, in the mists of time, (1987) I wrote a program that worked with hand held computers, barcode scanners, and was meant to be run by folks working in a power plant. I wrote the code, and got it working in about 2 months. It did everything in the spec, and the customer (Russ) loved what we had, but it turned out (of course) there were many things missed in the spec. A week or two later, we worked out a deal for…