BraveNewLinux's recent activity
-
Comment on Wirth's Law in ~comp
-
Comment on WebAssembly’s post-MVP future: A cartoon skill tree in ~comp
BraveNewLinux Link ParentEr, like 6 years ago. I'm sure it's been done a few times.I wonder how long it will be until someone [..] re-implements a rendering engine
Er, like 6 years ago. I'm sure it's been done a few times.
-
Comment on WebAssembly’s post-MVP future: A cartoon skill tree in ~comp
BraveNewLinux LinkFantastic read. WASM is going to be huge.Fantastic read. WASM is going to be huge.
-
Comment on How do you feel about where you live? in ~talk
BraveNewLinux Link ParentPlus it rains in LA. For days. That wasn't on the brochure (nor in any Hollywood movie, except maybe that Steve Martin one about the weatherman, but that was just for comedic effect).Plus it rains in LA. For days. That wasn't on the brochure (nor in any Hollywood movie, except maybe that Steve Martin one about the weatherman, but that was just for comedic effect).
-
Comment on Advice for internet startup newbie in ~tech
BraveNewLinux LinkIf you plan on leaving, that always makes the question of compensation tricky. Generally, a new biz doesn't have the money to pay you full rate, so they compensate with stock. But giving away too...-
If you plan on leaving, that always makes the question of compensation tricky. Generally, a new biz doesn't have the money to pay you full rate, so they compensate with stock. But giving away too much stock to a (former) employee is kind of a red flag.
-
Are your partners people you trust? I leaned the hard way to "never do business with people you don't trust". Contracts don't mean squat.
-
Blogs/etc take a loooooong time before they payoff. Be wary about thinking "this will get me business". In the beginning, you have nobody looking at your blog, so your blog posts literally don't matter. (And your website for that matter.) Find some biz problems and solve them. This is the only thing that matters. Don't undersell yourself, every biz deal must be profitable. It's OK to maybe do 1-2 jobs where you don't make a profit. Consider doing them for free instead of charging a wimpy rate, and think of them as paying for marketing material you can put on your website.
-
-
Comment on <deleted topic> in ~life
BraveNewLinux LinkWhat you are experiencing is partially captured in this podcast. Most people (and especially small businesses) have no way of telling good technology from bad technology. Therefore, it becomes a...- Exemplary
What you are experiencing is partially captured in this podcast. Most people (and especially small businesses) have no way of telling good technology from bad technology. Therefore, it becomes a market for lemons: Companies get the impression that IT is about rebooting servers, so they aim to pay as little is possible.
To move up in the IT world, you must get businesses to see you as a partner, not a servant. Get them to describe a problem they have, ask them how much it's worth if you can solve it. Instead of immediately jumping to a solution, you should spend most of your time figuring out what the actual problem is, and how they will know when problem is solved. For example, most companies will tell you they want "WordPress". But WordPress doesn't solve any particular problem. Really, what they want is "more visitors to their website", or "better conversion to paying customers", or something like that. WordPress is just a tiny (and arbitrary) part of the full solution, and people who just install WordPress are a dime a dozen.
If you can actually connect your solution to the value they get, they will gladly pay you a fraction of that value. That tends to be 10x to 100x what you would have gotten if you just charged "per hour" to do a menial task like "Install WordPress". Nobody will care how many hours it took, nor how easy/hard it was. What matters is that you showed them the value they got.
Most nerds in IT just like playing with the technology, and when put next to the CEO, they will continue to talk nerd stuff. It sounds like you have the right people skills to do IT the "right" way. (See also: patio11 on HackerNews)
I really liked being the guy who's called in when everything is on fire, everything is completely obscure and foreign, and I can somehow figure out how to put out all the fires
Problem is, people very quickly get used to that. You are no longer the "Hero", you are simply "doing your job" and anyone could do that, right? It can feel good to be the hero, but it's really making up for an unhealthy company mentality elsewhere, and it's not sustainable. Someone is creating those situations where things get fucked up. If it's you, you should just quit. If it's someone else, it's better to point that out and let the system fail because of them. You can be sure the company will spend resources to fix the problem. If you constantly shield the company from it's own mistakes, they will continue making them.
but then when shit hits the fan, and something totally unpredictable happens, I prove my value by fixing everything.
That's the wrong way to value yourself -- That feeds into the "Hero" mentality. It's much better if you can ensure that the shit never hits the fan. (Of course nobody will ever appreciate that. But it sure beats not being appreciated after you knock yourself out playing the hero.) Don't put "being a hero" in the budget, instead set realistic expectations all around. Sometimes it's as simple as standing up and saying "If we budget X, we can be back up in an hour. If we budget Y, we can be back up in 8 hours. If we don't budget anything, our disaster recovery could realistically take 24 hours." Some companies will gladly choose the 24 hours. You will grumble, but that's their choice, and they won't yell at you when it happens, because they agreed to it. And likely the cost of their downtime is much less than X or Y.
Heh, but sometimes that can come back to bite you. Developers get used to "not understanding the low-level bits going on". (At my company, we do 100's of SQL queries per page, when most of them could get away with just a handful.) Because developers only optimize (and look "under the hood") infrequently, they don't get good at it. In fact, they may look at "heavy" features, and tell the biz guys "it can't be done without 100s more servers", when in reality it could be done by being clever.
Of course, I'm not saying you should always optimize, but you should always know where your bottlenecks are, and spend a small fraction of time grinding them down.