Earlier quoted context omitted.
Way to describe the engineer/business disconnect. You are proud of the complex problems which you have solved over the years. The business is proud of the little widget that made everyone's jobs a bit easier. I've seen people take this lesson to heart and go full Wally.
>I've seen people take this lesson to heart and go full Wally. Who is Wally?
Evil programmer's tip: avoid “easy” things (2016)
181–190 of 203 posts
Re: Evil programmer's tip: avoid “easy” things (2016)
#182A classic "easy" thing that appears "hard": write a little bit of assembly. Note, a little bit [1]. Writing assembly, again, in small amounts, is exactly the kind of thing that is difficult to start, and fails spectacularly if you have little experience. Debugging is a pain. But you can totally get the hang of writing assembly, and as long as you are doing it for the right reasons (TM), it's justified, and heroic. Th…
> If you find yourself writing more than a hundred or so assembly instructions in a sitting, you are going to fail Why? (asking as somebody who wrote a lot of asm)
I find that I make a lot of mistakes with asm. When you've written hundreds of asm instructions in one change, because of debugging is superlinearly hard, one can easily spend a lot of time debugging. So now I write and commit in small chunks and test repeatedly. This has made me much more efficient by drastically reducing the time searching for where in the hundreds of instructions I've gone wrong.
Re: Evil programmer's tip: avoid “easy” things (2016)
#183Earlier quoted context omitted.
This is really easy to say, but having done pretty much exactly this for ages, finding management that doesn't take advantage of you in this regard is really rare.
I agree finding good management is a hard problem. It's also a very important one for engineers to solve. If you don't put effort into finding management that you work well with, you probably won't find it.
The problem is that management is free to tell you all these beautiful fantasies about work culture during the hiring process. There's absolutely no way for candidates to see if it's true or not.
So in that regard, I disagree. Candidates don't need to "solve" the problem of recruiters completely misrepresenting the workplace.
Re: Evil programmer's tip: avoid “easy” things (2016)
#184Earlier quoted context omitted.
God, this hurts. I pride myself in avoiding deadlines by looking to the future and getting things done before they're needed, so when the time comes, I can focus on polish and integration. But then some dick in management notices that I did this thing in a day, doesn't count the prep-work, and hands me an impossible deadline that's already promised to a customer...
In my fantasy world, the developers are the ones who make promises to the users and thats it
Hell, I'd settle for managers simply being held responsible when the impossible deadline they set wasn't met.
Re: Evil programmer's tip: avoid “easy” things (2016)
#185Earlier quoted context omitted.
I agree finding good management is a hard problem. It's also a very important one for engineers to solve. If you don't put effort into finding management that you work well with, you probably won't find it.
The problem is that management is free to tell you all these beautiful fantasies about work culture during the hiring process. There's absolutely no way for candidates to see if it's true or not. So in that regard, I disagree. Candidates don't need to "solve" the problem of recruiters completely misrepresenting the workplace.
Here what's worked well for me:
Always try to be a good coworker. Be helpful, friendly and competent.
If you do this well, you'll leave be 5-10 coworkers who are happy to recommend you at each job. They will also tell you the truth about culture where they work.
That's pretty much how I have done it.
BTW, one trick to learn the real culture is to ask engineers - not managers - during one on one interviews. Few engineers will lie to a potential future coworker in private.
Re: Evil programmer's tip: avoid “easy” things (2016)
#186Earlier quoted context omitted.
In the last 5 years I have probably written 100k+ lines of production code. My most celebrated feature was about 100 lines to store a single flag in a per user store.
Way to describe the engineer/business disconnect. You are proud of the complex problems which you have solved over the years. The business is proud of the little widget that made everyone's jobs a bit easier. I've seen people take this lesson to heart and go full Wally.
It was a little widget, just needed a bit of state persisted across sessions. The pain point was at page load, so about as far as most business pays attention. Also I do feel like it caused me to go full Wally without realizing it.
Re: Evil programmer's tip: avoid “easy” things (2016)
#187This works until your boss understands software development
> This works until your boss understands software development
Like that ever happens!
Re: Evil programmer's tip: avoid “easy” things (2016)
#188Earlier quoted context omitted.
> SAY NO TO URGENT ONE-OFF REQUESTS FROM MANAGEMENT!!! The thing is, saying no to requests from management (if it is your management of course) is going to hurt your career prospects too. Instead you should say "sure, but this thing will move the completion date of this hard and extremely important project X days, is it ok with you?" (Not having any hard and important project in the works? Fix that ASAP as the articl…
I know it's management's job to manage and obviously they have their own agenda but... In the past I've seen issues that I know will blow up at some point in the near-future. Fixing thing them would also make 3 other existing low level problems go away too. I've explained that to management but as they don't grasp an issue yet arisen they instead let me get half way through something else "important" when the issue s…
When you say, "I've explained that to management" -- was this in writing?
It works much better if you do this in writing, especially if this is a public medium you can refer to, like a JIRA ticket or a message in a public channel/mailing list. This way you at least can say, "I warned you but you refused "
Re: Evil programmer's tip: avoid “easy” things (2016)
#189Earlier quoted context omitted.
The problem is that management is free to tell you all these beautiful fantasies about work culture during the hiring process. There's absolutely no way for candidates to see if it's true or not. So in that regard, I disagree. Candidates don't need to "solve" the problem of recruiters completely misrepresenting the workplace.
Here what's worked well for me: Always try to be a good coworker. Be helpful, friendly and competent. If you do this well, you'll leave be 5-10 coworkers who are happy to recommend you at each job. They will also tell you the truth about culture where they work. That's pretty much how I have done it. BTW, one trick to learn the real culture is to ask engineers - not managers - during one on one interviews. Few engine…
That's not true. People lie all the time to prevent backlash against them.