4 ms·
Ask HN: Just what exactly is "real-world experience" and how do I get it?
This is in response to an old comment by edw519: http://news.ycombinator.com/item?id=226151
I've excerpted a bit of it here:
We are constantly hearing advice like "Scratch your own itch," "Find problems close to you," and "Code what you know," which is all good advice for finding a startup idea.
What then, do you do if you're not exposed to much?
When I spent time talking to people in SV 2 months ago, I noticed something I never expected: lots of people have very little exposure to "real world" problems.
People come up with "me too" startups because that's all they know.
Sure it's easy and cheap to start a business, and if you're smart and can hack, all the more reason. But what about the giant issue hardly anyone mentions: real world experience.
...
My advice to a young hacker with lots of skill but not much experience (outside of college apps): you may want to consider getting a job for a year or two. I know, everyone wants to start the next <whatever>, and get rich now and no one wants to sit in Megacorp's cube farm. And a startup, even a failed one, may be a better education.
OTOH, you will acquire dozens of great startup ideas (and contacts) and avoid the "me too" trap. Something to think about.
I found myself nodding in agreement as I read it, but I've been sitting here for 5 years in Megacorp's cube farm and I still don't think I have "real world experience." Part of the reason may be because this particular industry (aerospace) is also its own echo chamber in many ways, but I think I'm missing something.
Some people can enter a large organization, learn a lot of domain knowledge, and spot the pain points that can be solved with technology -- and potentially turn that into a lucrative startup or consulting career. Good for them. But these are the sort of "pain points" that I notice here:
- An extreme level of Not-Invented-Here Syndrome. I could not even get approval to use LAPACK for linear algebra computations. This ends up with a lot of wasted energy implementing things that have already been done, and probably much better than an in-house solution too.
- A stifling bureaucracy. It takes months of paperwork to get new hardware or software. All along the chain are little fiefdoms of people who will invent processes and regulations to justify their paychecks.
- A misalignment of incentives. Ideas get shot down because they threaten somebody's career. Buggy, unstable software gets declared a "roaring success" because nobody will own up to failure.
- A lack of honest communication between users, customers, management, and developers. Sure, it might be true that all enterprise software is like this, but it's clear that a lot of misunderstanding could be avoided (and the associated cost of doing the wrong thing could be saved).
If these are the pain points of an organization, I don't see how it helps me in any way. There's two issues:
(1) These are social problems, not technical, and they probably won't be solved with software.
(2) Even if there exists a software solution, there's probably no way to sell it short of employing a sales team that costs $50,000+ to make a deal (cf. Joel's article on pricing, http://www.joelonsoftware.com/articles/CamelsandRubberDuckies.html).
Yes, these are "real world" problems, but I don't see how I'm getting any useful "real world experience" out of this sort of environment. What should I be learning here?
- rawsyntax 16y agoBefore I got my first software dev job... I was told it's important to learn what you don't like as well.
- cydonian_monk 16y agoI could echo your sentiments (just for a different industry), but I won't to save space. There is always something to learn, though it may not be helpful right away. Product and domain knowledge not so much, unless you intend to compete in the same field, but most other things are universal. For example: • Social issues will exist for any organization, no matter the size. Knowing the outcomes and common signs, perhaps you can find a better way to prevent the issues you don't like. • Surely you've encountered some implementation bumps or failures in your tenure with MegaCorp. What caused them? How can you avoid them? These issues could be just as likely at a startup. • Think about the physical production/office environment, too. What could you change from what MegaCorp does that would make you more comfortable and productive? You may have seen a thousand ways that things are done wrong. Perhaps that's all you need to find the one way that's right. Henry Ford didn't develop an assembly-line controlled-labor auto factory by accident. Maybe he didn't know it would work, but he'd seen the ways it didn't work. Just like Edison with his electric bulb.
- byoung2 16y agoI've been sitting here for 5 years in Megacorp's cube farm and I still don't think I have "real world experience." As far as scratching your own itch goes, I think there is a disconnect between what problems you would like to solve for yourself, and what corporate deems worth spending money on. For a trivial but true example, I've noticed that every big corporation has no good system in place for reserving conference rooms. I'm talking about Fortune 500 and 250 companies where I've worked. At least a few times a month a whole team stops work and walks to a conference room, only to find it occupied. This leads to a 30 minute search for an empty conference room either on a different floor or in a different building altogether. I often wondered why these companies didn't invest in some cheap resource scheduling software or some scrappy startup's app to manage this process. It would save wasted productivity, but I bet department heads and ops directors would have a tough time getting that expense approved. So when you think about what problem to solve, you also have to think about who would be willing to pay for the fix