Your job isn't decision making but you can make sure management is fully aware of what they are dealing with. Outline major problems that you keep running across, you mention highly coupled platforms, that usually means changes in one system can have negative affects on another, and may not happen right away.
The big trade-offs for ignoring tech debt are software quality, system health and speed of development. Those things will get worse with time. If you bring up facts with evidence, on how those are poor because of the tech debt, it could help. Better yet, align tech debt with product strategy. For example, you know the product strategy is to do more X and system 1 is primarily involved with X but changes impact systems 2 and 3. Propose untangling system 1 from 2 and 3 as part of the effort with improving/building more X features. It really pays off when system 1 is loosely coupled from others and can evolve on it's own.
A common theme I've seen from some developers is basically to toss out the old system and build a new one. This usually never works. You probably need to start small with minor refactors to improve things and build credibility that refactoring is a path towards a better system.
When it comes down to it though, if management listens and mostly just ignores your advice, wait for the next failure and after it is resolved, gently (not "I told you so") bring it up again that maybe it could have been prevented.
Project leadership at a small company/startup is going to be much different than at a larger company and vastly different than at a Fortune 500. The path of a PM is typically to progressively manage more complex and larger projects whether in scope or budget.
A tech lead is a different role than a PM. Tech leads should be mentoring junior devs, guiding overall solution and working with a PM from a technical perspective like being a sounding board for crazy customer ideas.
Your company is small enough to keep dabbling in the project mgmt while coding. You don't need to make any decisions, just see where it goes. You may want to suggest to management that if there are enough devs doing PM tasks spread across X projects, at some point it might help to get a PM to do the PM stuff, then devs can focus more on development.
Having done the PM role, SW Mgr role, and lead engineer role, I found the PM role the most tedious/repetitive and missed coding. The problems being solved by a PM weren't technical and that is what I missed.
It ultimately comes down to what interests you more.
I think you missed the point of the article. It only matters for certain demographics. The byline says it all: "they can have a big effect if you’re not rich, not white, or not a guy"
I'm not sure what 'rich' means in the article, but if it means 'not poor' then for middle class white males it doesn't matter what school is on your resume.
Someone should create an app that translates a companies T&C into layman terms with simple stuff like "they track your location", "sell your usage data", etc. Just need a team of lawyers to interpret them, and a nice web site.
Call it something like AppSideEffects.com "Things that may be harmful when using these apps/web sites"
Retire. You can live off the interest if invested in mostly stable stuff (so I've heard) assuming you don't have a larger tax bill looming.
You may read lots of "awesome coder, great bizdev person" stuff online but 95% of the people out there in Tech are just working on someone else's idea/company bringing home pay. You are free from that now.
Be bored for a while and your interests will emerge. Take up a hobby, be a stay at home dad, think back to what excited you as a kid and explore those things.
My kids have put more of their money into Fortnite stuff in 1 year than they have paid for in total for any other AAA title game. So have all of their friends.
It isn't whales, its the 10-18 yo disposable money. They get into the stage where physical toys don't hold interest, their birthday and allowance money piles up and social/peer pressure comes into play.
It's been happening for decades though. Kids don't watch Saturday morning cartoons these days or wait to see what toy will be in the next McDonald's happy meal. They watch YouTube and see ads there.
Internet advertising isn't regulated but in a way it self-regulates. Content creators don't want in-appropriate ads and YouTube doesn't want that either when a channel is targeted for 8yo, it would make them lose money.
A great feature on Playstation is Family Management using sub-accounts. You can set time limits where it will log them out automatically. You can also setup a schedule with certain hours per day and end time.
I hear lots of "how much gaming did you do when you were young?" but it isn't the same. Today big game companies engineer the games to be addictive to "win" screen time. Back then I may have sunk a lot of time into Nintendo but it was mostly solo playing or playing with friends/siblings that sat next to you. You tended to help each other out to get past levels, etc.
Rails as the stack and REST as the implementation.
You can then spend most of your time on making sure you have a good understanding of the domain and then design the API to match that understanding.
Rails because you asked what _I_ would reach for :) Once you figure out your domain model you could just generate the REST API.
Rails has GraphQL gems so you could go down that path in the future if desired. Like anything though, GraphQL isn't a silver bullet. If you have a complex data model, that can be exposed and people unfamiliar with the data model will see performance issues.
When I hear API, I usually infer that it means other people will be calling it. The above answers are in context of that. If you really mean a back-end to your web app that nobody external will be calling, ever, then it really doesn't matter what tech stack or methodology you use. In that case, there are other factors like time to deliver and if there is a team building it, then it helps to use a common methodology (e.g. REST).
Large companies sometimes don't actually 'do' any of their own IT work. There are layers of SLA's across data centers and applications, spread across multiple vendors, contractors, etc.
Everything must have a legal contract that specifies support terms, penalties, etc. Large company's motives are risk avoidance to ensure profits for shareholders.
Basically companies will pay a premium to have someone they can call and yell at if something goes sideways. Usually corporate finance departments have no logistical way to accept a reimbursement from a vendor for missing a SLA but they like to put clauses like that in a contract.
The other part is the professional services arm tied to the sales process. RH can provide experts that only they can provide - they are the ones writing the code sometimes. Other companies like Oracle have professional services but I doubt they are committers on the products being sold.
There needs to be a paper trail. Newer technology is not the answer for voting.
What would be a good idea is a team to do UX on voting ballots, nationally. Solve this problem once and take into account all the variations of local things (bonds, amendments, etc.) Then pick a company to make ballot readers, open source the software and use best in class info-sec practices.
We don't need instant results, people don't take office at midnight of election day. We need accurate, transparent and verifiable results.
Also, make it a national holiday, close schools and just use them all as polling places.
I only skimmed the article until I realized they weren't talking about Apple starting a privacy focused actual social network. That's what I thought the article would be about.
So this is off topic but what I'm imagining is letting people connect with other iCloud users (aka friends and family) to share pics, videos and comment on them. Maybe they can link iTunes/App store content (apps, music, movies, etc.) with each other and comment on them too.
This might take a huge amount of more people off Facebook and bring them into Apple eco-system of services than meet-up like events at their brick and mortar stores. There are probably millions of FB users that just use it to connect with distant close friends & family to share pics, etc.
Edit: just to build on this idea a little, pulling people's actual social network (not acquaintances or long lost people they never see) could boost sales of their content. Let people share, like and comment on their favorite music, tv shows, movies, and apps with no ads.
There is a culture thing about MacBook Pro's being used by developers. The latest round of MBP has a pretty horrible keyboard experience, so home or at the office, I have it hooked up to monitor, keyboard and mouse. When I had a previous gen MBP, I used that as screen-1 plus keyboard.
I'd venture a guess that 95% of developers (myself included) don't need the horsepower a desktop could provide. I would have to try hard to utilize all the resources on a laptop too.
There are "standards" about REST and other mental frameworks about API's but when it comes down to it, everything is slightly different since there are so many small decisions that affect the end product like pagination and authorization.
Documentation with working examples someone can use via curl or Postman (or other API poking tool) is even better.
Tech stack doesn't matter, REST, GraphQL, micro services, etc. doesn't matter. People are calling an API to get some work done, they just want to know how to work with it - inputs, what happens and outputs.
The hosting country, like Russia, knows they are spies and puts surveillance teams on them 24/7. The spy's (aka CIA Officer) job is to make sure their agents (the host country people they are gathering intelligence from) will not be discovered because in worst case that may mean death for the agent.
I've read a few memoirs from CIA officers and typically they are doing a very well planned surveillance detection route (SDR) to ferret out who is following them. If they are headed to a clandestine meet, the plan could include disguises and specific parts of the route where they can lose the surveillance team. Then they can meet freely with their agent.
The sophistication isn't about technology of disguise, it is more about using a combination of the techniques described in the video and well honed skills.
The video describes mostly about what they would do under active surveillance e.g. people following them. Some of the prosthetics she describes also may throw off facial recognition.
The games are geared towards mixed levels of instant gratification and longer gratification, creating and maintaining an online character/persona, getting approval from peers as you climb the hierarchy of loot (character skins, rare items, etc.)
We limit their time and they are in other activities like sports which take time to develop skills.
Just be careful because some video games hire psychologists to help engineer a game to hit those neural pathways at the right intervals to get players to keep wanting to come back.
Getting really into video games can involve helping build a PC or maybe letting them create their own games.
The big trade-offs for ignoring tech debt are software quality, system health and speed of development. Those things will get worse with time. If you bring up facts with evidence, on how those are poor because of the tech debt, it could help. Better yet, align tech debt with product strategy. For example, you know the product strategy is to do more X and system 1 is primarily involved with X but changes impact systems 2 and 3. Propose untangling system 1 from 2 and 3 as part of the effort with improving/building more X features. It really pays off when system 1 is loosely coupled from others and can evolve on it's own.
A common theme I've seen from some developers is basically to toss out the old system and build a new one. This usually never works. You probably need to start small with minor refactors to improve things and build credibility that refactoring is a path towards a better system.
When it comes down to it though, if management listens and mostly just ignores your advice, wait for the next failure and after it is resolved, gently (not "I told you so") bring it up again that maybe it could have been prevented.