As long as software is a cost center to your company, it will be treated this way. Trying getting a job at a company where software is a core concern. Ideally with a CEO that is not from a marketing/business background.

For more on this sort if thing, Patrick McKenzie’s writing is good:

- https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...

- https://www.kalzumeus.com/2014/04/09/what-heartbleed-can-tea...

> In the real world, picking up a new language takes a few weeks of effort and after 6 to 12 months nobody will ever notice you haven’t been doing that one for your entire career.

Spoken as someone who has never taken the time to fully master a programming language and, from the sound of it, has never worked with someone who has either. The difference between someone who has spent 6-12 months with a language compared someone who has spent 6-12 years is night and day. From the general tone of the article, he obviously focuses more on the business value than on the technical side and that is a pretty good approach for making money. But I'll take Peter Norvig's advice (http://norvig.com/21-days.html) over this guys when it comes to mastering a language.

To be fair most of the content of those articles is pretty decent though and it is just a pet peeve of mine when people claim that mastery of your medium doesn't matter.

In my experience, having mastery over one language translates more or less directly into being at least journeyman in all others.

If you are working with an apprentice, whatever you do, it will seem like you are really experienced.

Thanks for posting that Norvig post. It's fantastic.

Thanks for the links! I really wish I read these when I was in my undergrad, they are really good!

In my experience, that's not necessarily actionable advice. (the first link)

You are right, great posts. Thanks for sharing.

One thing I've learned working in both kinds of companies is that having software as the core concern of the business isn't automatically a shield from bad project management or bad engineering management.

'Not considering software a cost center' is a necessary but insufficient condition for healthy estimation. A software company often appreciates you more, but is still susceptible to the other myriads of management pitfalls.

I have watched a manager with a master's degree in computer science pull this BS. At an enterprise technology company. He would go as far as repeating a question over and over until he got an answer he liked.

The senior members of his team had a culture of eighty hour work weeks. Draw what conclusions you may.

The biggest problem is that engineers tend to think in man-hours and managers think in calendar time. If I say a project will take 2 days, it'll probably take 2 days, but it might span 4 calendar days because other things are going on.

The biggest thing that has helped me here is to keep a running list of my tasks, an informal Gantt chart, and show it to the manager whenever they ask me about an estimate. This helps me communicate in a way they understand.

There's a lot of bad to be said about how companies use story points and velocity and all the rest, but I do greatly appreciate the way they delink "amount of work" from "delivery date". It's a nice built-in way of expressing time requirements separately from schedule, which is a lot smoother than constantly reminding people that the difference exists.

“Let’s just put some number in those boxes”, next thing you know it is signed on blood...

That's easy. Guess a number. Add some units. Double it. Double it again. Then double it again. Add a zero. Done.

Or, how to make people impressed by the fact that you’re always 10 times faster than your estimates.

This is a real thing that happens, but its frequency varies from organisation to organisation.

> People want ‘estimates’ at all costs, tell you to not worry about any accuracy, and then a week later tell your manager you committed to x date.

I like to handle this problem by providing an estimate RANGE.

That doesn’t really matter. In these cases you often have information akin to ‘we want a webshop’, so you estimate something more or less reasonable, then a few weeks later you find out they actually meant ‘we want a duplicate of Amazon’.

Typically when we need something budgetary from a vendor we use the +/- 50% rule. That shouldn't be hard not to screw up.