OpenDrapery's comments

You can't measure it before you join, just as they can't measure your effectiveness before you join. The best you can do is hit the eject button after 6 months after you've assessed what's really going on. Same goes for the employer's side.

Are you still doing consulting? I find that the upside of consulting is that there is a well defined finish line before you are deployed.

When you land in a role that has no finish line, it kind of removes the benefit of being a consultant.

What does acquiring the token do for you?

Kind of like Ohio State football

I feel like this is akin to working for a small company versus a larger company. Rules always cater to the lowest common denominator, because the people that make the rules are lazy and prefer blanket policies over stratified ones.

In a small team, the internet is not all clamped down at work. You are more likely to be treated like a mature adult. At a large company, they treat everyone like children because that one imbecile did that stupid thing that one time.

Now, the risk in acknowledging this phenomena is that you come off sounding elitist, "I want to join an exclusive club so I don't have the cretins dragging me down."

I've had interviewers try to school me on something that I wasn't super well versed on, and my internal thought process was "If I wanted to learn the finer points of xsd, I'd go dig in on my own and learn it. Right now I'm not that interested in you teaching it to me."

Maybe not the healthiest attitude ...

I think most young engineers are surprised to find that after they've navigated the hiring guantlet at BigCorp, they were never interviewing for a specific position to begin with. They were interviewing to be thrown into a pool of new hires.

When they show up for their first day of work, then they basically role the dice to determine whether you go to team A (interesting work) or team B (shit work).

I'm wondering if all the people who can't get over the name CockroachDB are also people who insist that professionals should dress the part. Can't take someone seriously if they don't have their shirt tucked in?

Style over substance.

Agreed on the quality of employment. It's quite eye opening when you realize that a company will pay you $100k salary, basically to "own" you.

Show up for work at the designated time, sit in your assigned seat. Sometimes you will get interesting work. Most times you will get menial tasks. Sometimes you won't get any work at all.

After the first month, you're thinking, "Uh, I was here about the software developer position? Are we going to be building any software?"

le sigh

Throwaway, prototype, proof of concept, spike, playing around, whatever you want to call it. In many (most?) businesses, they never get thrown away. They form the basis of the product.

In other words, the thing that makes software so unique and valuable, is the very thing that most organizations don't take advantage of. They think that if you throw it away, you are scrapping something akin to physical materials.

Shame, really.

I saw it written somewhere that when we were young, we had freedom but no information. Today, kids have all the information, but no freedom.

Proof once again that life is a series of tradeoffs.

Funny that you mention that the report writer becomes the person closest to understanding the business.

In my experience, the report writer many times is the developer on the team who drew the short straw. So you get this weird effect where the best way to learn the domain is to end up with the least desirable project work (from a dev perspective).

When the developer is the domain expert, you've achieved the singularity. /s

A large percentage of the time, there is no domain expert available, or there simply is no domain expert. We've all worked at that place. You start a new job and you're left to your own devices to sink or swim. You wonder why no one can be bothered to take the time to give you the big picture. Who is the customer? Who is the user? Are they the same person? What problems are we trying to help them solve? Are we optimizing for speed, correctness, usability? How do our competitors do it? Who are our competitors?

How about some backstory on this codebase? I can look through source history like I'm doing an archaelogical dig. But how about a narrative on why certain choices were made?

The reason no one will take the time to answer these questions for you is that they will quickly be exposed as not having answers. The best they can do is say "I'll have to ask so and so", and then you'll never hear back.

Also, there is a pervasive vibe that when you're brought on as a developer, it's not your place to ask business-y type questions. Let the people person talk to the people, and you dig ditches where we tell you to dig them. And if we ask you to fill it back in because we told you to dig in the wrong place, well then, you're here 40 hours a week and work is work right?

/end rant

Sorry guys, my fingers just kept typing.

So, when a team of 12 delivers a product that makes X amount of money, we say to ourselves, "Each individual on this team has an output of X/12 ? That's silly.

Also, your comment, "Why, by performance of course." What does that even mean?

Would love to hear more detail about how you would measure productivity and output of a programmer. Because there are millions of managers around the world who have yet to figure it out.

Management/Educators/Government will always cater to the lowest common denominator(LCD). It only takes one person to screw it up for everyone. This is the real upside to working for a small company. The larger the company, the lower the LCD is likely to be.

I admire large companies that have the balls to delineate between groups. Most don't. If you work as an IT professional for a company that has a large call center, God help you. Call center work is some of the highest turnover work out there. Managers of call centers resort to treating they're employees like children.

It is frustrating when you find yourself as a college educated, fully formed adult, being lumped in with cretins.

IMO, this is largely why work from home is squashed. Because if we let you do it, everyone will want to do it, and we can't have that.

I'm still looking for a dev job in Columbus, OH where I can be part of the engineering team, and not part of IT. Seems that all of the dev jobs are in the IT cost center around here.

The decision maker always spins open office as some kind of collaborative, productivity enhancer. But we all know the real reason is cost.

The things that I enjoyed at 25 years old are not the same things that I enjoy at 40. Well, some are. But not all.

Sounds like we've found the guy who has the secret to measuring productivity. Care to share what the rest of the industry has yet to figure out? How, on earth, do we measure developer productivity?

Right on. Can we cut the bullshit about how a wage worker is supposed to care about the customer, the business, or any of that? Does the person working in the drive through at McDonalds care about the customer? Of course not.

Now, if I was a partner in a business with some equity stake, then I would mop the floors if that's what I felt would increase the value of my stake. But as a wage worker, when you tell me to mop the floor, I tell you "that's not my fucking job".

People act in their own self interest. Why is this so god damn difficult to understand? Fuck!