Keep a document of your design decisions. It's very tempting to hack away to get things done, but human memory is short and feeble: you will forget why stuff was coded the way it was faster then you think.

I usually keep a Google Docs page open where, as I write the code, I update the documentation. It keeps things consistent and flexible, and much easier to go back and refactor.

I think this is key when you are working with code you don't touch every day.

On code you touch every day one can easily make changes since everything is fresh in one's mind.

When you are working with a code base that you touch once a week or even for a few hours/minutes every day having notes about what you did, why and perceived next steps at the time is crucial and VERY useful.

Another strategy I found useful is to try and be consistent with your choices even if they are not fantastic.

For example: all your tables are named like tbl_entityNam. Even if prefixing every table with 'tbl' is a bad idea, the consistency in keeping it will be useful later when you need to work with that code.

From Brazil, Beholder: https://beholder.tech/en/

Although not yet doing automatic checkout, but most of the technology needed for it is there.

For me particularly the greatest difficulty was in understanding what was going on, and how people's effort was contributing to the company's goals. There always seems to be a lot of activity on individual tasks, and project managers will take strong interest in making sure that their project is on track, but higher up the chain of management I have always had trouble seeing where all the pieces fit together.

I would love if it was possible to have attributed to everything that is done in a company an array with scores that will indicate how well that effort is a fit for the company's goals. Then it would be simply a matter of having sensible metrics and an easy way to get the information. I imagine that's what KPIs are supposed to be doing, but somehow there doesn't seem to exist an easy to implement strategy for making them effortlessly intuitive and useful.

My dad had a vynil LP with BBC sound effects, which I remember listening to when I was a kid. I particularly liked to listen to the disaster sounds, like cars skidding and crashing and, shockingly, a crowd of people being shot at.

My dad did the sound effects for the local amateur dramatics group and he had a few of these records. He would record them onto reel to reel tape and edit them with a small guillotine, sticking them together with special tape. Incredibly primitive and time consuming by today's standards.

:) I wrote a couple of tables on Excel v1 that was running on the original Mackintosh we had at home to play around with the same equations.

This has been in my mind recently. I am head of development at a startup and have something like 30 direct reports. I don't want to be doing this job for a long time, and am maneuvering the team structure to make myself redundant with the following actions: - I am trying to convince the execs and HR to increase pay transparency and to reward people who want to progress in their careers as engineers more than those who want to become managers. - I have promoted one person with more leadership skills (and less technical ability) to be a dev lead; essentially a mentor, gathering feedback from the team and helping them solve process and communication issues, and keeping track of OKR metrics. - I hired a department assistant, to do resource allocation, manage Jira permissions, tidy up boards, etc. - We have 1 project manager who is responsible for our three internal development projects, controls our budget and fights with other PMs for resources. - All others are Developers and QA. Some are more senior, so they have architecture roles. Everyone gets to give their voice, but one of them has an official role of architecture lead, who has the final say, but that's mostly cerimonial.

My role is to help them focus when they start to drift, shield them from politics, and most importantly give a cerimonial ratification on their ideas, if they match the values of the company.

So all 4 non developers are essentially assistants. I hope to soon be able to step out and leave the team working happily with a 10 to 1 ratio of dev to non-dev.

30 direct reports is an astonishing number, and it makes me feel like you're either onto something brilliant or are crazy and this structure is going to crash and burn once things get really complicated and fast-paced. I suppose it depends on how routine a lot of the work is. You'd be spending a minimum of 15 hours a week just on 1:1s, but I could see that being as high as 20 or 30 hours; 15 is already two full days out of the week. That is, unless you just don't do 1:1s at all, which seems incredibly risky long-term.

Given a six-month check-in and annual review once a year for each report, you'd have a total of 60 such events a year, meaning you'd have at least one annual review or six-month check-in every single week. You'd have to keep up with the unique performance characteristics of 30 different people in order to conduct these reviews in any reasonably useful and professional way that actually encourages real growth. If there's any sort of interpersonal conflict or unexpected project complexity, this could easily burn through enough of your time that you'd have to blow off nearly 30 people in the meantime.

Yeah, I started doing 1-on-1 with all of them when the team was about half size. The reason I got one of the guys "promoted" as dev lead is so he can take most of the mentoring and feedback gathering. He is not their boss though, with no authority to assign work or make demands.

Nowadays I do 1-on-1s with the dev lead, the assistant, and the product owners (senior devs and architects), so only 5 people.

Still, that would mean the dev lead would need to do 25 1-on-1s, so we have a structure of peer mentorship, with two phases: a formal and an informal. The formal is to maintain quality of information gathering and fairness. The informal is to allow for rapport and flexibility in the part of the mentor. We started this recently, we'll see how it goes.

This solution sums up the problem. When you have many of those dev leads, the least capable among them will be promoted to be their leader. This is human nature in group formation.

Calling it an alternative to SageMaker might be a bit misleading, as SageMaker is also a platform for training the models in automatically allocated EC2 resources, even on spot instances.

We've changed the title from "Cortex: An open source alternative to SageMaker" to the page's own title, as the HN guidelines request.

https://news.ycombinator.com/newsguidelines.html

Cortex contributor here - you're right, I would say we can be compared to SageMaker model deployment. We are currently working on supporting spot instances for serving, and training is on our roadmap.

I never give any information to anyone who calls me, apart from people I already know like friends and family. If they say they are from the bank I apologize and say that I will contact them independently via the number that is on my card. I don't even confirm my name. Some banks think I am being difficult, but I stick to this principle regardless.

I think it's more likely that some scammers think you're being difficult. Shouldn't that be standard procedure for a bank?

It makes perfect sense when you think about it.

I did think about it. Before I posted I spent more than just a small bit of effort. I still don't see what the difference actually is though. Yes I know what "but" means. I know all those words... but...

I do not see any actual difference. Anything you apply those two descriptions to are both "off-topic" as well as "interesting", according to those descriptions. The "but" does not make any difference at all as far as I can see. The other replies say there is a preference implied (I already knew that that was the intention), but as I just wrote, however you parse it, you end up with both attributes and I don't see any preference actually being applied. I see the attempt, yes, but I don't see that there is any effect.