171–180 of 522 posts
???
I rather enjoy fixing bugs, particularly really hard ones. They can be fun logic puzzles that take some sleuthing to figure out and offer multiple pay outs... First time reproducing it. Figuring out the problem. Figuring out the best fix. Test case fail -> test case pass.
Earlier quoted context omitted.
I know someone that worked at some skeezy company in Menlo Park that got passed up for a raise after spending months navigating the bureaucracy to save the company millions on their operating costs because they didn't write enough code. This was in the last four years. Edit: And they quit right afterwards.
It’s better to find ways to make more money than to save it. There’s a floor but no ceiling in much of what we do.
The maths is simple. If my margin is 1%, and you make me an extra $100, I keep a buck. If you save me $100, I keep that whole $100. If I'm smart, I can use that to drive my prices down, and take more market share without reducing my margin.
Obviously it becomes less clear if your margin is >20% or so.
A variant of this that has driven me to quit more than one job is having a non-technical manager look at a UI prototype and consider that 90% of the solution. "The UI guys had this page ready two months ago! Why doesn't this work yet?" It's even worse when you present a working prototype. They simply don't understand that the backend functionality is what's doing the bulk of the work, and just because you can see som…
> look at a UI prototype and consider that 90% of the solution Management tip: Make the UI reflect the actual state of the project. The UI should be UGGGLY and should get prettier as the backend work gets finished. If if the artists prettify it; make the animations and interactions janky and sluggish. Never make the UI better than the actual implementation. Bonus tip: Always have something slightly off in the UI that…
For instance, Bootsketch: http://yago.github.io/Bootsketch/
I wish some of the bigger CSS frameworks would adopt sketch theming support as a "progressive" option, rather than the entire page all or nothing being Bootstrap or Bootsketch have the ability to add a "sketch" class to any element on any page. (Or maybe better yet, forcing sketch styles by default and needing something like a "final" or "final final" class everywhere, like the documents folder of someone that has never understood source control.)
I recall a story about someone at a government contractor who did a major refactoring and removed thousands of lines of code from a project, increasing its performance, only to be told by management that they'd signed a contract that said the company got paid by lines of code delivered, and his improvement would cost them tens of thousands of dollars, so revert the whole thing.
As long as we are counting LOC before compiling, that can be solved easily: if (false) { /* original code stays here, as we are payed by LOC */ } else { /* write your new code here */ }
> Some developers would have immediately gone back to the person reporting the problem and required more information before investigating. I try and do as much as I can with the information provided.
Some developers have a hard time with interpersonal communication but you can't isolate yourself if you're working in an org. That mindset will inevitably make you less effective (I learned that the hard way).
Earlier quoted context omitted.
Also, never use the word "done" in any context in a meeting like that. Do not even say: "I'm not done". They won't hear the "not". Say, "Development is still in progress" or something similar. I got chewed out for something being released (where it was found to be broken) to a customer because I said something like: "I'm about 80% done with testing, but I haven't run into any issues yet." They released it even though…
Did you really get chewed out? That seems pretty much like a deal breaker for me. Managers are collaborators, not parents, and have no place talking to co-workers in such a diminutive manner.
It was my first professional development job and I learned a lot of things. One of the keys was this:
Your boss and employer are not your friends. When you promise something to your friends, you owe it without any expectation of reward or return. But your employer owes you something for everything you give them. If they fail to meet their end of the bargain, that's on them and you are absolutely 100% free to leave. That can be money, time off, good working conditions, respect, trust, or any number of things. For me money was not primary (though it is nice): I wanted a good work environment, interesting work, and respect. Fail any of those and I will be looking for an exit, even if it's just a transfer within the same company. But respect is first in that. A boss who shows little respect to his employees is not someone I want to be around. I had that boss who chewed me out, I had another that kept me doing busy work for a year and kept saying worthless platitudes like "you're important to our work, we can't do this without you" when everything pointed to that being false. He was just empire building and trying to grow his direct report count, but it hurt those of us under him because he didn't have the work (but he did have the money) to keep us there. (I was still relatively junior at that job and stayed longer than I should've.)
[0] The hierarchy was something like: VP of Engineering (several divisions below him) -> Chief of Engineer (Aviation) -> Chief of Software (Aviation) -> Chief of Testing (Aviation) -> Me; other production lines had similar chains below the VP.
[1] When she was my manager I quit, or more accurately transferred to another group. Years later, I quit my last job for several reasons, one was her. She was not in our division while I was in that position, but they'd just hired her on. When I heard the name I had to verify, when I confirmed it was the same person I was ready to exit.
A variant of this that has driven me to quit more than one job is having a non-technical manager look at a UI prototype and consider that 90% of the solution. "The UI guys had this page ready two months ago! Why doesn't this work yet?" It's even worse when you present a working prototype. They simply don't understand that the backend functionality is what's doing the bulk of the work, and just because you can see som…
> look at a UI prototype and consider that 90% of the solution Management tip: Make the UI reflect the actual state of the project. The UI should be UGGGLY and should get prettier as the backend work gets finished. If if the artists prettify it; make the animations and interactions janky and sluggish. Never make the UI better than the actual implementation. Bonus tip: Always have something slightly off in the UI that…
Do people actually have fights like this with management at their companies? Not trying to knock the author, but I'm just surprised anyone would actually hear this kind of comment in 2020. I'd think by now any and all metrics tying lines of code to productivity would be long dead.
$JOB-2, admittedly about 4 years ago now, the good manager with a background in software left for a better opportunity and was replaced by someone who's background was management. With no insight into the subject matter, they fell back on whatever they thought they could quantize.
Got numerous things like that, though my team lead and our project manager did a great job of shielding the team from that crap, we still occasionally hear it come up in group meetings and the like.
I even got a task handed directly to me, bypassing everyone above me, to "estimate how much it would cost to migrate all those linus apps your team has to windows. They'll run better there". Just the windows licenses alone would have cost us about half the existing server costs since we were using AWS instances. Also included a line item that included recruitment costs for a new developer, and verbally informed him that it would likely involve hiring a new team, as the existing team was hired specifically as linux developers.
Earlier quoted context omitted.
Yes, very much like the time I replaced a getfakedata() method with a getrealdata() method and then management complained that it was much slower now.
After this (and a few emergent race bugs), I started burying the equivalent of setTimeout(() => getFakeData(), 1500) in my similar code. Best part is, I'm almost certain to beat 1500, so I've gotten compliments that it "feels snappier".