|
Also, having someone make a bad/weird technical decision and nobody is able to tell them "no".
|
#
?
Mar 27, 2017 16:24
|
|
|
|
| # ? Apr 19, 2024 12:17 |
|
|
Aren't startup all about sunk cost fallacy anyway ?
AskYourself fucked around with this message at 16:33 on Mar 27, 2017 |
|
#
?
Mar 27, 2017 16:30
|
|
|
AskYourself posted:Aren't startup all about sunk cost fallacy anyway ? More like they're all about whatever path will get them to the next round of investor funding. In a functional startup that will generally mean building on top of the existing code, warts and all, because you're trying to ramp up and run lean and don't have the time/resources to address technical debt. In a nonfunctional startup you just kind of do whatever until the investors lose patience and liquidate you. 
|
|
#
?
Mar 27, 2017 16:53
|
|
|
So either way, it seem that what the seniors and management are working on is really important to keep the business afloat and to ensure that Link get a paycheck. So in that regard then yes it's a rite of passage to understand that sometime, even if it they have little or no technical merit, effort is spent in way which might appear to make no sense in order to accomplish strategic goals and objectives.
|
|
#
?
Mar 27, 2017 17:11
|
|
|
AskYourself posted:So either way, it seem that what the seniors and management are working on is really important to keep the business afloat and to ensure that Link get a paycheck. I don't see how spending a huge amount of managerial time and effort on directly building a tool you don't actually need because you can buy a replacement off the shelf is going to keep the business afloat. This is exactly the kind of thing that a) the manager should have delegated to someone to investigate feasibility on, b) the manager should have accepted said delegate's opinion of "nah, we should just use this COTS solution", and they could move on getting something actually important done. When the investors come knocking, they're not gonna be happy to learn that your entire team sat around for months with their thumbs up their asses because the manager was busy reliving his engineering glory days instead of actually leading.
|
|
#
?
Mar 27, 2017 17:16
|
|
|
Except the managers and Seniors (save for one) haven't actually produced anything yet lol I've written more code than anyone on the team combined. Also, no more investors! "We" got acquired by the parent company and 2 of the managers are from that company and one is my boss, the VP of Engineering, from the acquired company.
|
|
#
?
Mar 27, 2017 17:17
|
|
|
Good Will Hrunting posted:is this bad luck or am I just learning the way of software development at start-ups? Startups are just companies stripped slightly more bare. SA and YOSPOS like to poo poo on them, but mostly it's based on fiction. I've worked at startups for the past 8ish years, make great money, and have loved most of my jobs until I've gotten bored of them and moved on (with one exception, which was fine until the end). The thing that makes most discussion of startups irrelevant is people apply the term to all sorts of tech companies or situations. 400 person company, funded mostly by Oracle, making garbage enterprise configuration software? Startup (they have a video game room). 2 bizbros with an app idea (doguber) trying to hire you for 0$ and 2% equity? That's a startup. Facebook and Google? Yeah, they're the best startups! 40 person, profitable bootstrapped all-remote tech company? Startup! I don't think any of those are really even wrong, just, it's kind of meaningless to lump all those companies into the same bucket: they literally cover the range of working at Oracle to being unemployed. Most companies are poo poo, like 90% of jobs will give you a low grade lust for  . You have to filter the ones out that aren't. Honestly, I think it's easier with startups or smaller companies because there are many signals you can see easily that translate more directly to the current state of the company.
So most of those things are sort of holistic company indicators. They only sort of speak to the day to day work environment, but some of them help (CTO resume, founder history). Anyway, you still need to be asking all that, plus some when you interview. That's why you interview, to find out if a company is full of crazy assholes or not. Big companies aren't immune from being full of crazy assholes, in fact they're a lot more likely to be full of crazy assholes IMHO -- but it cuts both ways: plenty of deeply embedded, never leaving crazy assholes, but probably their hands are tied by bureaucracy a bit more so the effects on your day to day are more muted and predictable.
|
|
#
?
Mar 27, 2017 17:18
|
|
|
I find that I am happiest when I'm somewhere in the employee #3 - #20 range. The company is small enough that I have a fuckton of agency, but it's big enough that there's a bit of stability (if you can't find out financials, you shouldn't work there) and things like 'paying people' and 'health insurance' and poo poo have already been figured out.
|
|
#
?
Mar 27, 2017 17:21
|
|
|
Good Will Hrunting posted:is this bad luck or am I just learning the way of software development at start-ups? this is all pretty much de riguere if you are lucky the founders/early employees have a strong grasp of product and are able to make intelligent decisions on what to prioritize. you may have technical debt but you at least have good answers to product questions if you're unlucky no one really knows/cares about product and you get flippant, useless answers to product questions and you get feature requests that conflict with product constraints and other features and everything ends up grinding to a halt as you end up with an untenable code base and no one to make the decision to address technical debt that is killing velocity
|
|
#
?
Mar 27, 2017 17:24
|
|
|
Good Will Hrunting posted:Also, no more investors! "We" got acquired by the parent company and 2 of the managers are from that company and one is my boss, the VP of Engineering, from the acquired company. IIRC they sprung it on you right after you were hired? Complicated ownership is usually a bad sign. Even having a parent company usually indicates either the place is dysfunctional, or the genesis of it is parent company wants a 'scrappy' i.e. lovely, corner cutting, doesn't answer to normal chain of command division. There can be exceptions of course if the parent company is a good place, and they know how to spin off divisions sanely.
|
|
#
?
Mar 27, 2017 17:40
|
|
|
Yeah I had no idea my team would be mostly managed by 2 people from the parent, who I didn't even speak with at any stage of being interviewed and didn't know would be managing me until 2 weeks after I started. This adds a whole new level of stress tbh, as I feel like now I'm constantly trying to prove something in fear of them being unhappy with my skill set as a fit for their team. It's a brand new domain for me, one with a fairly steep learning curve, so this added stress also hasn't helped.
|
|
#
?
Mar 27, 2017 17:46
|
|
|
Honestly I'd say you should hit the job trail again. It's a better use of your time than trying to fight the team structure you've become embedded in, and no hiring manager will blink at you joining a startup for two months and then quitting, especially if you tell them about the acquisition.
|
|
#
?
Mar 27, 2017 17:55
|
|
|
TooMuchAbstraction posted:I don't see how spending a huge amount of managerial time and effort on directly building a tool you don't actually need because you can buy a replacement off the shelf is going to keep the business afloat. This is exactly the kind of thing that a) the manager should have delegated to someone to investigate feasibility on, b) the manager should have accepted said delegate's opinion of "nah, we should just use this COTS solution", and they could move on getting something actually important done. You are right but that is if the investors learn about it. How often did you see investor come down the trench and ask coders if the company is being efficient with their resources. I'm talking out of my hat. I don't know tons of startup and I'm actually judging from my own experience. I doubt he can change anything about the culture there tho.
|
|
#
?
Mar 27, 2017 18:12
|
|
|
One approach that I've found very useful for big decisions is to imagine that it's a year from now and I'm perfectly happy having stayed in whatever situation I'm thinking about getting out of. I then ask how I went from thinking about leaving to wanting to stay. If there are no plausible scenarios, then it's time to get out. If there are plausible scenarios, then it's time to start thinking about how likely they are, and make decisions based on that.
|
|
#
?
Mar 27, 2017 19:27
|
|
|
ultrafilter posted:One approach that I've found very useful for big decisions is to imagine that it's a year from now and I'm perfectly happy having stayed in whatever situation I'm thinking about getting out of. I then ask how I went from thinking about leaving to wanting to stay. If there are no plausible scenarios, then it's time to get out. If there are plausible scenarios, then it's time to start thinking about how likely they are, and make decisions based on that. Write it all down too, this will help you solidify your thought process.
|
|
#
?
Mar 27, 2017 19:27
|
|
|
I'm trying to gauge, at this point in my career, what I should expect from a job and what my role should be. Am I expecting too much? Am I not doing enough to make it better? Things like that.
|
|
#
?
Mar 27, 2017 20:02
|
|
|
AskYourself posted:You are right but that is if the investors learn about it. How often did you see investor come down the trench and ask coders if the company is being efficient with their resources. The other point of contention with all this talk: y'all know technical debt can be good right? Just like regular debt? You can incur it for the right reasons.
|
|
#
?
Mar 27, 2017 20:11
|
|
|
Good Will Hrunting posted:I'm trying to gauge, at this point in my career, what I should expect from a job and what my role should be. Am I expecting too much? Am I not doing enough to make it better? Things like that. Regardless of where you are in your career, you should expect to have a reasonable amount of work to do each week -- not so much that you're overwhelmed, but not so little that you're twiddling your thumbs either. And you should expect that work to be challenging and to drive you to improve yourself.
|
|
#
?
Mar 27, 2017 20:15
|
|
|
JawnV6 posted:I've had an interview interrupted by an investor to the VC fund for a startup doing due diligence. It happens. I stand corrected then  Yup technical debt is a tool. Can be traded for opportunity cost and time to market not exclusively.
|
|
#
?
Mar 27, 2017 20:50
|
|
|
AskYourself posted:Yup technical debt is a tool. Can be traded for opportunity cost and time to market not exclusively. I will say that, similar to actual debt, this situation is incredibly rare and usually technical debt is being accrued because people are bad at planning ahead.
|
|
#
?
Mar 27, 2017 20:55
|
|
|
AskYourself posted:Yup technical debt is a tool. Can be traded for opportunity cost and time to market not exclusively. Not exactly like normal debt. Can't just take out a huge 'technical loan' and buy something useful with it. It's more like not cleaning your house. At some level, it's not a big deal, but if you end up like some hoarder, you end up having to just tear the house down.
|
|
#
?
Mar 27, 2017 21:05
|
|
|
Maybe this is too e/n, but does anyone have a good, unambiguous definition of technical debt? Under the rough description of "engineering is identifying, refining, and solving problems", tech debt to me always implies "this solution will noticeably do poorly under some circumstance X" where X might be something that can happen presently or something that isn't even possible at the time. Under that line of thinking, tech debt is "risk that the way we solve stuff with code/systems now ceases to be a good solution at some point in time."
|
|
#
?
Mar 27, 2017 21:15
|
|
|
vonnegutt posted:I will say that, similar to actual debt, this situation is incredibly rare and usually technical debt is being accrued because people are bad at planning ahead. prisoner of waffles posted:Maybe this is too e/n, but does anyone have a good, unambiguous definition of technical debt? Technical debt makes the most sense when Money debt is going to crash you sooner. Do you know how much re-writing and replacing even a series A can pay for?
|
|
#
?
Mar 27, 2017 21:26
|
|
|
prisoner of waffles posted:Under that line of thinking, tech debt is "risk that the way we solve stuff with code/systems now ceases to be a good solution at some point in time."
|
|
#
?
Mar 27, 2017 21:30
|
|
|
prisoner of waffles posted:Maybe this is too e/n, but does anyone have a good, unambiguous definition of technical debt? Under the rough description of "engineering is identifying, refining, and solving problems", tech debt to me always implies "this solution will noticeably do poorly under some circumstance X" where X might be something that can happen presently or something that isn't even possible at the time. While it may or may not be a perfect analogy, real debt is a good way of thinking about it. You often accrue technical debt when you skip some normally important development step. Maybe you didn't write tests. Maybe the infrastructure is done by hand rather than defined programmatically. Maybe you didn't refactor as you went along. Maybe you decided to put Dave Who Knows SQL on the database ticket again rather than Steve Who Should Probably Learn SQL. You choose one or more of these shortcuts because they save time and get you to some important externally-enforced goal, the logic being that you can go back and correct the known failings you've just introduced *after* when you have more time and money, so it'll be OK that it'll take more time and money than if you do it now. The impact of deferring these good code practices (slower development time, more fragile codebase) and the extra payback cost is the "interest" on the debt. You take it on because not doing it now will gently caress you for non-development reasons. If "later" never comes and you keep taking on more debt then you'll eventually find that the interest is so high that you can't reasonably function, most of your development time is taken up paying off the interest and not the debt itself. Paying that down usually involves shutting down feature development for months or years. The story of gov.uk is one of mountains of tech debt accrued out of necessity and paid off over years of hard effort, I can tell you more about that if you're interested.
|
|
#
?
Mar 27, 2017 21:31
|
|
|
All this talk of the tech giants has got me wondering if I should move that way myself. I've been in startup or post-startup culture for over a decade now.
|
|
#
?
Mar 27, 2017 21:43
|
|
|
Arachnamus posted:All this talk of the tech giants has got me wondering if I should move that way myself. I've been in startup or post-startup culture for over a decade now. If you've never experienced working for a tech giant, it's probably worth doing at least once, just like you should experience working for a startup at least once if you can afford the risk. The wider your breadth of experience the less likely you are to end up in a job you hate because you don't realize there's better options (at least, better as far as your personal metrics are concerned).
|
|
#
?
Mar 27, 2017 21:56
|
|
|
TooMuchAbstraction posted:If you've never experienced working for a tech giant, it's probably worth doing at least once Seems like it requires commitment to the long haul, though? Ready acceptance of things like the aforementioned CS-algo–heavy interviews and year-on-year ladder climbing.
|
|
#
?
Mar 27, 2017 22:12
|
|
|
I interviewed at all start-ups except Google and they all asked algo poo poo.
|
|
#
?
Mar 27, 2017 22:21
|
|
|
Arachnamus posted:The story of gov.uk is one of mountains of tech debt accrued out of necessity and paid off over years of hard effort, I can tell you more about that if you're interested. I would find this interesting. Good Will Hrunting posted:I interviewed at all start-ups except Google and they all asked algo poo poo. How is google a startup!?
|
|
#
?
Mar 27, 2017 22:48
|
|
|
Arachnamus posted:Seems like it requires commitment to the long haul, though? Ready acceptance of things like the aforementioned CS-algo–heavy interviews and year-on-year ladder climbing. You've got to pass the interview but beyond that you're not really forced to accept the long haul any more than you are anywhere else. If you don't like it go work somewhere else after a year
|
|
#
?
Mar 27, 2017 22:51
|
|
|
return0 posted:
Did you read my post lol
|
|
#
?
Mar 27, 2017 22:59
|
|
|
return0 posted:How is google a startup!? VOTE YES ON 69 posted:The thing that makes most discussion of startups irrelevant is people apply the term to all sorts of tech companies or situations. 400 person company, funded mostly by Oracle, making garbage enterprise configuration software? Startup (they have a video game room). 2 bizbros with an app idea (doguber) trying to hire you for 0$ and 2% equity? That's a startup. Facebook and Google? Yeah, they're the best startups! 40 person, profitable bootstrapped all-remote tech company? Startup! I don't think any of those are really even wrong, just, it's kind of meaningless to lump all those companies into the same bucket: they literally cover the range of working at Oracle to being unemployed.
|
|
#
?
Mar 27, 2017 23:01
|
|
|
Good Will Hrunting posted:Did you read my post lol It's grammatically ambiguous. It could be saying everywhere you interviewed was a startup except for Google (which is what I'm sure you mean) or you interviewed at all of the startups except for Google.
|
|
#
?
Mar 27, 2017 23:26
|
|
|
No Safe Word posted:It's grammatically ambiguous. It could be saying everywhere you interviewed was a startup except for Google (which is what I'm sure you mean) or you interviewed at all of the startups except for Google. That would be terrible English if I meant the latter.
|
|
#
?
Mar 27, 2017 23:40
|
|
|
Good Will Hrunting posted:That would be terrible English if I meant the latter. Hrunting for the right words? You're sentence was crap.
|
|
#
?
Mar 27, 2017 23:42
|
|
|
Yes, that's a totally reasonable interpretation. He's a person that considers Google a startup, and interviewed at every other of the startups that weren't Google. Actually thinking that is what he meant is more stupid than the poorly written sentence. On topic, technical debt is a reality and nobody can reasonably avoid accruing it. I've worked places that tried to do literally everything right, and perfect, all the time, and not only was it a horrible experience where nothing of substance actually got done, but the poo poo that got done still wasn't actually very good.
|
|
#
?
Mar 28, 2017 04:33
|
|
|
Steve French posted:On topic, technical debt is a reality and nobody can reasonably avoid accruing it. I've worked places that tried to do literally everything right, and perfect, all the time, and not only was it a horrible experience where nothing of substance actually got done, but the poo poo that got done still wasn't actually very good. The trick is to look at it in terms of cost/benefit analysis. How much does it cost you to require your code to pass a linter before it can be submitted? How much does it cost to do code reviews? The benefits from a few relatively small things like that will likely massively outweigh the costs. On the flipside, the cost of trying to design and implement the One True Design that not only achieves the stated immediate goals but also leaves room for all the potential future expansions you might want to take? That's gigantic, and also doomed to failure because you're always going to discover that your One True Design wasn't really equipped to deal with reality. So you try to make a reasonable design, that will probably achieve your immediate goals and ought to be reasonably easy to rewrite when you discover that it no longer meets your needs. This is basically guaranteed to result in some amount of technical debt, but it's a managed amount.
|
|
#
?
Mar 28, 2017 04:46
|
|
|
TooMuchAbstraction posted:The trick is to look at it in terms of cost/benefit analysis. How much does it cost you to require your code to pass a linter before it can be submitted? How much does it cost to do code reviews? The benefits from a few relatively small things like that will likely massively outweigh the costs. Isn't that also kind of the point of design patterns and encapsulation? You can never, ever plan for every possibility but you can get an idea of what the program is meant to do, pick an appropriate architecture, and build from there.
|
|
#
?
Mar 28, 2017 05:09
|
|
|
|
| # ? Apr 19, 2024 12:17 |
|
|
Every abstraction leaks.
|
|
#
?
Mar 28, 2017 05:09
|
|