OpenDrapery

Kudos to the company for taking onboarding seriously. Most places are abysmal at it. But then again, I've recently been working at places that leverage a lot of contractors/consultants to get work done. The attitude seems to be, "why bother giving them context? They are just here to labor and then be gone."

I was thinking along the same lines. Hiring units of people sounds like a slippery slope to collective bargaining and unions, which have turned into bad words in the US in the last 30 years.

I guess there is a fine line between collective bargaining and holding a company hostage.

Remember when the cast of Friends all negotiated for $1M/episode, and they pitched it as "you pay us all, or you don't have a product"? I don't recall any public outcry that they were holding NBC hostage.

As we move toward a completely digital society, it only makes sense that the digital gatekeepers will have more leverage. Employers hate that.

If you are not asking questions like this, you may just be one of the willfully oblivious ditch diggers who is just there to work. And that's fine.

Even in the days of galley slaves, there was probably only a small percentage of rowers who actually wondered where they were going. Most people just shut up and row.

Is buying a guitar in hopes of learning how to play it an investment? What exactly are the fundamentals? Do I need to understand vibration and frequency? Or just basic music theory?

I agree with your sentiment. But there is a difference between experimentation and investment.

I was thinking the same thing. I wonder how much of it is due to the way we make devs work and the hours we make them keep.

For example, I'd be more than happy to use the same old, tried and true, boring tools to just get the job done, if it meant that I could then go play golf or otherwise not be in the office.

But if you insist that I be in my seat 8 hours a day regardless of workload, then goddamn let's take this shiny new tool for a spin!

Do I want my resume to show that I used the same tool for every job for the last ten years? Or do I want it show some new hotness?

The industry and employers are as much to blame for this as the engineers, if not more. When you use middleman firms to find your employees, and all they understand is buzzwords, well then guess what game the devs are gonna play?

It feels like QA is an antiquated notion these days. Why is a prod-like test environment too much to ask for? As a developer, if you call me in the middle of the night and tell me we are in crisis mode, my first thought might be "Did anyone test this thing with any kind of rigor at all?"

Sad truth is that coding and problem solving and getting your hands dirty is low status work. I've had managers that new the application they were responsible for, and could speak coherently about technical things.

I've had managers who couldn't demo the apps that their team worked on.

Which one is better to work for as an engineer? The technically savvy one. Which one has higher stature and seems to be more highly regarded by his superiors? The non technical one.

In other words, that "lazy shitty manager" is probably playing the game better.

I really like that you use the term "engineers". Columbus has way too many employers that use the term "IT".

I think the Yankees model is a (possibly reaching) metaphor for capitalism. All the capital concentrates in a few hands. But where are all the "best" people supposed to prove themselves?

That's why you see so many posts in this thread like "I worked on the perfect team for a short period, but alas, it was short lived." Building the gestalt is always going to flame out. Right at the moment when you realize you've assembled something special is when your team members start getting traded to the Yankees.

That's why the only sustainable model is culture, culture, culture. Always be striving for the perfect combination of team members. Keep the talent pipeline active, and if you have someone who doesn't fit, get them out of there.

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!