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.
> for middle class white males it doesn't matter what school is on your resume
That's not what the studies show. What the studies show is that, if you're a well-off white male who is in the top 1% academically then it doesn't matter, long-term financially, where you go to university.
I mean, I found the article interesting but that's a pretty niche bunch of chaps right there.
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"
That doesn't make much senser. As soon as you wrtite a legal document in "plain English", whatever that may mean, you would find out how bad plain language is at capturing the endless nuances of actual life that need to be captured in contractual language.
I also don't actually find the current language of TOS prohibitively obfuscated, even though English isn't even my first language. The trouble is length far more than phrasing.
What could possibly work is to codify certain recurring segments, i. e. specify them once in a (complicated) law, then represent them in an understandable format, such as a visualisation. The "Nutritional Informations" come to mind.
Alternatively, a certification scheme grading different levels of data protection could work, such as it is currently used for organic food.
Or, you know, just outlaw the stuff that no sane person would ever accept unless forced to by the market converging on one, very low, standard.
> Or, you know, just outlaw the stuff that no sane person would ever accept unless forced to by the market converging on one, very low, standard.
I think this and legislation requiring a good faith plain text explanation of terms would work well together. You can have the legalese for the details, but many (most?) Things people care about can be talked about plainly.
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.
Retiring is pretty dull at age 43. Maybe work on something you're into but which doesn't necessarily bring in much money. Personally, also having some money, I'm working on startup idea to fix the world etc which currently brings in zero money but is fun. Maybe it'll turn in to something real later, who knows. By the way re investing I recommend mainstream stuff like blue chip stocks, income producing real estate etc.
I "retired" in my mid-20s for about 3 years. I only went back to work when I ran out of money.
Describing complete freedom as "dull" is an insane concept to me. You can work out, read, watch TV, go to coffee shops, cook, or even just sit around all day with no commitments.
I agree. I am 46, and my wife was joking a few years ago that we're living a retired's life. (I'm working from home, but at a rate that's about ten times the local average, so it's pretty much whenever I feel like it.)
Not everyone is like us. I'm a relatively successful software engineer currently and I still think back with fond memories to when I was tech support sitting there answering 30 minutes of calls per 8 hour shift. For some people that's torture.
It should be more than a "hope." If you really retire (and really plan to never work again), you should have some reasonable confidence that you will never run out of money. Having 25x to 30x current expenses saved and invested is a good starting point.
Sounds like you have enough to live off of, with a little planning. Enjoy the time you get to spend with your family. Find a few things that interest you, taking some random classes, try new stuff. Were I in your shoes, I'd buy a home with enough dirt to build a shop and I'd tinker.
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).
It might seem like overkill at first, but if you start a project from Sinatra, you’ll end up implementing a lot of rails features that won’t be as well thought out or integrated. If “weight” is a concern, it’s pretty easy to turn off rails features that you don’t need.
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.
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.