davismwfl
Then I like to check out the database (or algorithms & data structures if no db) and see how data is stored and manipulated, usually tells you a lot about choices that have been made.
Then open the project(s) and trace those 3-4 workflows once I understand it from the top level workflows. Part of this is also of course, getting the project(s) loaded and building locally as needed also reviewing tests, CI/CD, dependencies etc.
Lately, I've used Claude Code to help me with this, have it build a function map or class map and have it breakdown key insights about the code and trace those few workflows for me that I then validate. My process is pretty much the same just Claude does a lot of the initial lifting. I'll also dump the entire DDL for most databases (if they are more then a few tables) and send it to Claude and use that as a way to look for patterns/issues etc. For older monolith apps I've had to break the DDL into chunks sometimes just because some of these older apps have a very large number of tables/indexes/constraints etc that have been added over the years. Same thing works for json stores too fwiw.
Copilot for code completion + reviews or small snippets/functions but larger code/module generation has been weak so far.
Claude for full modules generation or complex multi-file edits.
Research: Grok (less filtered + better search), Claude (complex dev topics), GPT (balanced but sometimes slanted and/or seems to favor certain sources).
My Teams: Mostly Copilot for code completion/reviews, mix of GPT/Claude for code. Last year was loose/experimental to learn but we plan to formalize guidelines more this quarter.
Definitely a ton of hype that doesn't always match reality, but it is a super powerful tool that really has made things move faster.
My take (and hence assumptions) is you want to build a product where other engineers utilize your stripe account while charging fourth parties. I believe standard stripe accounts only allow for end use, not intermediary use. e.g. you can not "repackage" stripe to a third party and allow them to charge on your stripe account. If I understand things properly too, this actually wouldn't even be a Stripe only restriction, this is a restriction by many (most) card networks.
Definitely not a lawyer and not an expert on all things credit card. I did work on a project that tried to do something like this. Our client was wanting to allow their resellers to charge for unrelated products through the companies merchant account. This is essentially repacking and they got smacked by the bank and told this is not allowed by card networks. Now, whether it was just that bank and they lied about the reasoning or not I cannot say. But I know the networks are super touchy about knowing who is charging, for what and the risk profiles etc
I am pretty sure the SV3C brand is just a rebranded Dahua or similar, just a little different software.
FWIW: I also never use their mobile app to set them up, I just plug them into the isolated network and use the web interface to configure them.
I use BlueIris for the NVR software (it is cheap) and I buy various cheap IP cameras that support OnVIF (almost all try to phone home, some directly to china IPs). But what I do is I put all the cameras on an isolated LAN that does not have access to the internet. My BlueIris server has two NIC's one for the video lan and the other for my data network. BlueIris has a static IP and is locked down as well to what it can access externally.
Two ways you can make BlueIris work outside your home, use a VPN on your mobile device (absolute safest), or use their free DDNS to point to your box. Their system seems fairly decent, and I've done both methods. I also log all the requests on both LANs and check them every so often to see what is happening.
It seriously doesn't cost much to set this up, especially for just a couple of cameras.
I also have direct knowledge of a couple of other startups, similar size of 20-30 people in engineering, and they are about the same, no more than ~6 people.
In most cases, people really shouldn't be accessing production, it should mainly be deployment tasks that do. But you need a certain number of people to have access to cover failures etc. For example, having at least 4 people provides coverage if one person is on vacation, and then another gets sick etc.
I've read other companies basically have every engineer has production access to what they deploy, not sure I agree with that approach but I can see the argument.
Generically, most hardware based companies today are really software services or data companies that have a hardware "interface" product. e.g. pick a consumer wearable product, what's really the product there? the hardware? or the users data? The answer is generally the user's data and insights that can be pulled from that data. So product led there generally starts with the insights and data, the hardware is just a means to acquire it.
My main point is unless you are selling primarily disconnected hardware, e.g. a non-connected toaster, you almost always are focused on the software services and data around the product and the hardware is just the bow you wrap it in to get what really is your product. So being product led for hardware isn't so different than SaaS or others. The one key difference is part of the user experience is the hardware, so you spend more time around optimizing the hardware and convincing customers why your shiny object is the one they need to buy. In the end though, usually those reasons to buy still boil down to the insights that come from the software. Hence you are still looking at all those growth metrics, engagement etc that most SaaS or software based business are watching.
If you are a truly non-connected or have severely limited software in the product then I'd have some different comments, but those are pretty rare in today's market.
I am also not doing Java, primarily either node.js or C/C++, or I am using DataGrip.
That same example could be used for most of technology. I am sure Musk understands ML at a pretty solid level, but ask him to build or train a model and my guess is he wouldn't show "competence".
I think technical competence is also different then "could do it", e.g. I think Musk, Zuck could sit down and figure out most software related tasks. But it isn't a good use of their time. They have a good enough understanding of the technical limitations and requirements to lead people in product creation which has proven immensely valuable.
I like to always build a project dictionary early on, as it just is helpful for everyone coming along later, and also if concepts change over time the original intent is clear. So like in this case, I'd just pick "attributes" and then have a markdown file or wiki etc that has common terms, and attributes would be described with examples. A quick 1-2 sentence write up is way easier then trying to spend a lot of time picking the perfect word/phrase.
I learned C in the 80's and C++ in the late 80's/early 90's. I have heard every few years since probably 1996-97 how C/C++ were dead or dying languages and had no place in modern development. Yet they both have continued to grow in usage, especially with the IoT push.
I happen to still love working in both C and C++, not that they are the most productive or best tool for every job, but for high performance or low level, embedded etc they are still a great fit.
FWIW I feel most languages have a purpose and when used for those purposes they excel. However, when you use a shovel to pound in nails, it isn't the tool that is the problem. I do see languages like Rust replacing a lot of things C/C++ have been used for, but not everything.
Jobs are a little more selective for C/C++ in general, but there are tons out there and good C/C++ devs do well.
I've seen people calling themselves full stack but in reality they don't even have an area they know well and so they are just weak across the board which makes it hard to even give them a chance. Pick an area, spend your time there first and once you are fairly solid there you can start branching into more parts of the stack. I do think it is smart to branch wide across many areas, but you need some depth in an area first to help you land a job and be productive for a team.
I personally never witnessed reasonable quality engineers not able to move around and find work (outside a short 6ish month window during the peak of the dot com bust), sure it took a little longer for some, but we are still talking like 2-3 months. I changed jobs twice during the dot com bust and recovery as well as during the 2008 cycle, but I had solid experience. The people who were mainly laid off were the inexperienced that didn't have a tech degree. e.g. where companies took a chance on training them to fill a tech role which they were struggling to fill during the boom cycle. People regardless of degree or no-degree that had 5-10 years did fine generally, and 10+ years did well as long as you were reasonable in salary requests.
The biggest issue I saw was salaries stagnated for a really long time and companies took advantage of the job market to hold the salary growth down. To be clear, salaries didn't go down so much as they just leveled off and stayed there for WAY too long IMO.
There was some good that came from the dot com bust. The market weeded out all the speculative job seekers who had no business writing code. It removed a lot of the poorly ran companies, and it forced companies to pay attention to the fundamentals. So it wasn't all bad either, and I think we were healthier after for quite a while.
Hopefully this cycle turns into another correction and we clean up some stuff and it happens quickly. Nothing says it has to be a horrid all or nothing event, most recessions aren't. 2008 was unusually tough on a lot of people but left the tech area relatively unscathed. This one won't be quite the same, but HNWP & LP's need to still put their money to work, so there will still be plenty of money for decent companies. And tech is everywhere and not optional for companies anymore, so there will be a market for good engineers and like positions.
My general rule is newly hired team members can't rewrite systems or major components within their first few months on the team. Of course it isn't an unbreakable rule, but the goal is to make them fully understand the product and clients. A lot of times people want to rewrite things cause they don't understand the problem you are solving and by rewriting the code base they can dig into the problem more. When in reality if you force them to live with the existing codebase for a bit it can help them and you feel more comfortable with a rewrite if that becomes necessary and usually it goes better too.
I've seen devs use react for landing sites that are 3-5 pages and maybe a couple of forms etc all because they didn't know how to interact with forms through javascript. Or one I loved is a new dev saw jquery in a project we had that was still operational and doing great but he freaked out wanting to rewrite a stable cash cow of a codebase cause jquery is "bad". I doubt/hope that isn't your case here, but just make sure you feel confident in the reasoning and it isn't just cause they know react and it is the hammer they use regardless.
FWIW too, a lot of newer managers, and younger people just don't know these laws/rules simply because they haven't ran into them yet. So it is common to have them make, sometimes odd, requests with no malice or bad intentions, just out of a lack of knowledge.
tldr; make sure you work at least a few hours that week and that generally forces your employers hand.
Some states have specific laws on the books so you should always check, but even if they don't there are already a set of federal laws protecting employees. Basic rule is exempt employees are to be paid for the jury time, though there are a few potential loopholes. The advice I was given though was just pay up as it isn't worth the headaches later.
The reality, if you work 1 hour during the entire week, from home or at the court house, or train ride in etc, you have provided services for your employer and are entitled to be paid. There are some thoughts (maybe rules) that state if you do no work during the week and take a full 5 days off that the employer can ask you to take PTO or go unpaid, but they cannot punish you in any way.
California likely has more detailed laws around this so I'd check just to know. I will say, when you are bootstrapped as I was and have someone gone for a week that isn't a nothing impact, it hurts. The reality is I could have likely gotten the employee free from jury duty because it was a hardship to the business (yes that is real), but to me that is just wrong and sends the wrong signal to everyone.
If you are working for a startup, it is likely they just don't know the laws and are trying to figure it out too, so I'd not be a jerk about it but also be up front. If they are a larger company, they likely know the rules and are trying to be less than fair and skirt their responsibilities to the system and to you.
obligatory, IANAL, just have paid a number of them over the years for professional advice.
Generally on my teams those who do their work and contribute to making the team, company and product more successful get promoted (when ready).
Those who hurt the team are worked with to fix the issue and only after much effort to try and correct issues is someone let go.
tl;dr - performance or lack of, and team dynamics positive or negative are what drive those decisions.
To that point, I recently had someone ask me how I learned some of the things I did on distributed. I am not disagreeing with other commenters about reading up and studying but I think that it isn't as good as experimenting with things yourself.
Pick something like "leader election" and implement a naive/simple version of it so you have a better understanding. Take that and run it in AWS on 3 (or more) micro instances and play with failure scenarios. Alternatively you can do the same with local computers on your network, or raspberry pi's or any other SBC. For less than the cost of a text book you'll have real world experience implementing and experimenting.
From there, try other scenarios and keep building and testing. Doing this is far more valuable then just reading about it. Then if you do hit a job where you need those skills it isn't just academic to you, you'll have played with how it works and seen how to debug issues etc.
Speaking of debugging issues, one of the hardest things in distributed systems is just that, debugging. So build a basic (again maybe naive version) distributed logging/tracing solution so you can see the issues first hand. You'll then understand (at least somewhat better) the way to evaluate the common solutions/ideas that are on market or that people push.
You can learn a lot even by just setting up something like zookeeper or etcd and learn how they work, failure modes and how they can help or hurt you.
Just some ideas, but the basic concept is to actually implement things. Even just run your tests in containers (not as good IMO but still better than just reading about it) if you can't afford to spend a little money in AWS or on SBCs etc.
*edit fixed a word mistake
In the 90's I had a large book collection that I used for learning and for reference which served similar purposes. That plus the man pages and SDK docs you got with libraries was basically your goto. And even then, we still had programming forums (BBS) and usenet for finding help and samples.
Oh and if/when you did Microsoft programming keeping the MSDN docs on your machine was an option, which was like 4Gb if you installed it all.
FWIW: I do fairly often write code without internet but if I am using a library I am unfamiliar with or need to do something that is less common I'll save some docs or key web pages locally to help me.
I'd say in your situation, no, the salary isn't important and in fact may work against you tax wise. But you'll have to make sure the corp is doing a real business as there are some rules around parking, though I am not an accountant or attorney so my understanding may be incorrect. Good luck!
On that note, hopefully you registered in your operating/home state already too and got all that out of the way as that is another pain point a lot of people miss early on when they register a Delaware corp. Frankly, unless you plan to take a VC based round soon the Delaware corp is really a liability for new solo founders just starting out. If you are bootstrapping it is almost always more simple, faster, easier and less prone to issues to manage a state based LLC or S Corp that you setup with the proper structure to support moving it to a C corp later. Talking to an attorney and/or accountant makes all this so much easier and prevents you from winding up on the wrong side of an equation unintentionally and unexpectedly.
You don't need to spend tons of money, but get some advice from an accountant and/or an attorney on these things to make sure you don't wind up spending $10k in liabilities to save $1k in fees.
A degree is what helps you early in your career to get a foot in a door, or a slightly higher starting pay or position etc. In the end, it is your ability to sell yourself, deliver and most importantly be personable and work with people of all types.
For the most part in tech, whether I am hiring an exec or engineer the only time I actually will look at/for a degree (or certificate) is if I am hiring someone with no professional experience or filling a highly specialized role. Frankly, too much time spent in university is a negative indicator to me, unless you were specializing in a research heavy area or needed it for a professional certification like a medical doctor, attorney etc.
FWIW, some degrees and certain schools on a resume are a negative indicator to me as well. This is because over the past 20+ years I've seen the type of people they produce on average. That isn't to say I won't interview a candidate (or hire them) if they seem like they are a potential fit, just that I'll dig pretty deep to see if the candidate avoided the issues I am aware of. More traditionally "top rated" schools/programs are on this list than basic public state universities.
At any good company, it always boils down to the person in my experience, not a piece of paper. And it should be noted, C level and other exec's usually get hired through referrals, their own network or headhunters and not generally through blind resume submittal. So it is generally a much more personalized process than applying as a basic engineer etc.
When I review a resume I look for short stints where the person was an FTE (or freelancer) as generally it is a sign they have a hard time being a team player, or they look for any small reason to self eject versus work through issues. Companies aren't perfect, not one of them, so there will always be one or more reasons people can use to eject, but you need to stick it out some and learn how to work through issues.
In general (specifically in tech), if you stay a minimum of 2 years no one will really care much if you move on, under that and you have to be more cautious how you present and discuss it. I'm not saying I wouldn't interview someone with 1-2 stints under a year. But if you have ~3 years of experience and have had 3-4 jobs it better be clear to me that the jobs were planned as short term gigs or something specific like 1-2 of the companies failed etc.
One strategy you can try is to arrange your resume not in chronological order but about skills and projects you've worked on specifically. This sometimes gets you past the resume review stage though the short stints will come up and you'll need to have a good reason why you are worth taking a risk on. The first one that was because of relocation is fairly easy to justify so I doubt anyone dings you for that, but the others will raise some eyebrows and potentially concern.
If you are just prototyping and not ready to create a relationship then use one of the online plans with a provider or Twilio etc until you are ready. You'll generally pay a bit more doing this, but for prototyping it gives you more options and you can try different providers etc.
Code comments are important (sometimes more important than the code), even for code that seems self describing, as in many cases putting a few notes of the "why" is super critical to prevent people from making breaking changes later. That said, I am not advocating for commenting completely self describing code lines, e.g. // for loop etc.
My personal work style is I first write comments as the outline of what I want to have happen then fill in the details via code. At the end, I'll remove the unnecessary comments, but by doing this it helps me make sure my code is fully commented and helps me organize my thoughts before just writing code. The worst case is I sometimes leave unnecessary comments but that's fairly minor IMO. This method works at any level of code too, e.g. modules, interfaces, files, functions etc
Frankly commenting this way has saved me countless hours of debugging, especially in more complex and code dense functions, algorithms is a good example. Non trivial lambdas is another good example where a good comment can save a ton of time.
I also require function header comments with parameter descriptions and return value details etc. Tools like doxygen are invaluable when you work with teams that need to share details on interfaces etc.
I'd echo a couple of comments, apply for roles you think fit your skills. Startups call people with 2-3 years senior all the time and I'd not consider the vast majority of people filling those roles as senior. It all depends on their categorization.
I've seen people create career levels in startups that are totally out of line with reality but they use them. So worry less about title and just make sure based on the job you think you can do the work and deliver. Don't be afraid to reach "up" though, plenty of people with your type of experience can out deliver more senior candidates, it all depends on the person.
One of the hardest tasks for a company, especially right now, to do is to create the resume funnel. So I know some startups try to hack it and create FOMO on their hiring funnel, which is what the claim you heard sounds like to me. Yes, certain brand names will get crazy number of applicants, but that isn't the case across the board.
General jobs/economy reality. The more positions open when there is low unemployment (relative to the position) the smaller number of applicants per position, and the pickier the applicants. The fewer jobs open with "high" unemployment the larger and less picky candidates become. After the dotcom bust, when I was hiring we would see 500-1000/month resumes per open position in some cases, just insane; yet, before the bust we would see < 100/month usually, even at highly known companies.
Other hints. Streamline your process, but don’t follow big tech hiring strategies. It is moronic for a small startup to act like Netflix or Meta or Google. Most startups lose good candidates because of the process being poor or disrespectful of the candidates time.
I run a simple process and can get candidates through in a matter of 2-3 days usually, assuming they can make the time too. Recent example, first call on a Thursday, tech interviews on Friday and offer on Monday. That’s how you compete against the tough market conditions and larger startups who can pay more. And even then it isn’t perfect, we lost that candidate cause he had offers higher then we felt we could pay for the match. Good for him, but his feedback was very positive to the recruiter about us and the process.