5 ms·
How many TechCrunch articles can you find where an acquiring company says "the software we're buying doesn't really work, but it sure looks good!"? I just left
by save_ferris 9y ago
How many TechCrunch articles can you find where an acquiring company says "the software we're buying doesn't really work, but it sure looks good!"?
I just left a job where the founder (who didn't have any software background) deeply ingrained himself with this philosophy and wound making life a living hell for engineering.
While building a full-stack prototype, we slapped bootstrap 4 on the front end because who has time to roll CSS when the project is months behind schedule?
The founder with no sofware experience decided that bootstrap was terrible and that he'd roll an entirely custom app style. So he went into the codebase on a weekend and ripped out all the views/controllers/assets and replaced them with his own, which massively broke the test suite on Monday morning (which of course he didn't know how to operate or fix.) After a couple of other "executive audibles" like this, I took the next good offer and ran.
It's weird to see 'visual design' as a mainstay of an article titled 'What you should know as a founder of a software company', as if managing a team and building solid engineering fundamentals and culture are either assumed or unimportant.
- ivm 9y agoIt's not a mainstay, I wrote that you don't need to focus on design instead of functionality and that a $50 template will be ok. The goal is to develop a sense of good design, so you can pick a good template or hire good designers later and argue about the results of their work.
- john_moscow 9y agoIt keeps on puzzling me why don't engineers ever speak up. Like "Hey, man, I understand the old design sucks and you want to make it better, but editing things directly would only make the delays bigger. How about you take a few screenshots of the product, photoshop it the way you would like it to look and then we, as a technical team, will use our best expertise to make it look this way without breaking everything in pieces?". That could have saved you from weeks of hell and would also increase your influence by a great amount.
- throwawaydoom 9y agoBecause "shut up or find yourself another job". I thought this too until recently -- got fired after trying to protect my employer from a toxic exec. There are some that do not accept anything but yesmans or silent codemonkeys. It sucks but it pays. If you are not willing to lose your position, just let it go.
- golergka 9y agoIn my experience, it's "shut or find yourself another engineer".
- marcosdumay 9y agoNormally, people that does that do not know enough to care about keeping good technical staff. What is also another good way to say that, shutting up or not, they deserve to be out of an engineer, so go immediately looking for another boss.
- john_moscow 9y agoProtecting your abstract "employer" from a toxic exec is a political suicide. The right thing to do is sniff out who's the exec's political enemy and what move is he planning next against him and aid that person in his move without directly confronting the toxic exec. It's dirty politics, but it works.
- throwawaydoom 9y agoYeah.. Lesson learned I hope... Am I naive to think that in a business setting, problems should be constructively confronted proportionally to the extent of their damage potential directly with their author? Wouldn't the business be able to grow more efficiently and be able to keep a peaceful environment free of backstabbers if people could accept that everyone makes mistakes, that they don't really matter as long as they are fixed quickly, and that they are all learning opportunities that can become valuable assets? I feel like am I throwing buzzwords around and that to some extent I have always heard this in a form or another but for some reason, never seen it put into practice.
- vacri 9y agoApple got to where it is (=more liquid cash than the US government) off the back of good looks and fashion.
- onion2k 9y agoWhere I write code we use git hooks to run linting and unit tests on pre-commit and integration tests on pre-push, and anyone using --no-verify gets a stern talking to. No one gets code in to the repo if it breaks the tests. I'm still working on a way to stop commits that drop the coverage below a threshold so even new code can't be added if it isn't tested.