massung

So, this is from the other side of the table. Every place I interview, with every person who interviews me (phone and in-person), I always ask:

"If there was one problem here that you could snap your fingers and magically 'fix', what would it be?"

Then I usually follow-up asking what they consider the "fix" to be.

If there's a systemic problem at the company, usually the answers among the different employees will be quite similar. If I notice that, along with possibly similar solutions proposed, as I interview up the food chain I'll ask specifically about it. If I get a dismissive response, then I know to turn down any offer.

I always feel like the idea of "clear" vs. "clever" is missing the point.

When I've come across - or written - "clever" code in my career, it's always been about making something that normally wouldn't fit into memory - or perform slowly - viable. The examples of this are numerous and still happen plenty today on modern hardware (e.g. games, VMs, NaN tagging). There is nothing wrong with "clever" code so long as it's _clearly_ documented and abstracted away with various types, macros, functions, etc.

Then there's all other code. And what I feel the author wanted to say was that anyone coming along later shouldn't have to think twice about what a given line of code is doing.

If there's a bug, sometimes I'll be lucky enough to have a debugger, sometimes not. But, I shouldn't have to second guess a line of code to determine whether or not the bug is there. In your nested ternary expression, I would be second guessing all over the place; what's the precedence? Hell, whenever I use ternary operators I still force myself to parenthesize the conditional, because while operator precedence in C/C++ is well defined, it's not well known.

Clarity is another reason I prefer type safe languages over dynamic ones for critical code. It allows me to be a little more "expressive" with my code where the reader coming along after-the-fact can be assured that everything works out type-wise.

Having worked on code that people's lives depended on, there are times when getting it wrong isn't an option. I can only feel for the software engineers of the 737 MAX going back over gobs of code and trying to dissect what went wrong and come up with a fix. They'd be heavily scrutinizing every line of code, and I can promise that a nested ternary would be very scrutinized. But, so would a deep chain of if, elsif, elsif, ... and recursive functions (which are often a _big_ no-no in mission-critical code). Although, I don't think anyone here effectively argue that recursion is something to be considered "clever".

It's all about a code reader being able to _prove_ to themselves that the code does _exactly_ what it looks like it does and nothing more.

I'm not a Rust fanboy, but - just like static type checking - the borrow checker adds one more level of surety to the reader that another thread isn't coming along and stomping over the data. And this is without needing the whole context of the code base. This is a _big_ deal.

Anyone know if this will affect the internal use (e.g. EMR) s3 schema: s3://bucket/path/key?

Option 4: sell your ride data to a 3rd party. Knowing who you are, where you travel to, what's around those areas. They - or a 3rd party - could advertise what's in the area you were taken to, track where you frequent and recommend riding to places you haven't been to in a while showing you what's "new" in those areas, etc.

I don't Uber (and have only used Lyft once), so maybe they already do this or are planning to.

Doesn't this presume that "sad music" is - in fact - sad?

There's plenty of music I will sit and listen to that my daughter asks me to turn off because it makes her sad, but I find very uplifting. Examples:

https://www.youtube.com/watch?v=lUpvEgJEn94

https://www.youtube.com/watch?v=tIcR7Xkysds

There are plenty of other examples as well. All the studies reveal to me is that we're all wired a little different. Shocker.

> When it comes to pay, it’s an inherit property: you’re looking to max out your pay, and they’re looking to minimize.

While I can understand what drives this statement, I believe it's fundamentally flawed (from both perspectives).

A business is attempting to minimize and maximize many things simultaneously. One of those should be maximizing employee "happiness" for the purposes of retention, productivity, etc. Similarly, they are attempting to mimimize costs. The employee is also working to minimize and maximize many things at once. And, similarly, one area they work to also maximize is their own personal "happiness".

So, at a fundamental level, the employee and a good employer should both have they employee's happiness as a stated goal of something they'd like to maximize.

Happiness (personal and professional) can mean many things. And, an employer has many levers they can pull to help improve an employee's happiness. Sadly, one of the fundamental problems that exists in a typical employer/employee relationship is that there are very few things that an employee feels they can discuss with an employer in an attempt to maximize their own happiness; salary is typically at the top of that list.

When an employee finds their happiness tanking, it could be for many reasons. And, salary could be a cause of the unhappiness. For example, maybe the employee has taken on considerably more work in the past year and doesn't feel fairly compensated for it. But, it's quite often been my experience that the issue is actually something else entirely, and the employee is just grasping at one of the only levers they see available to pull on in the hopes it will make them happier (spoiler: it rarely does).

An example (true story) would be the Day Care provider used by the employee is no longer an option, forcing them to look for new Day Care options (highly stressful), and they are either farther away and/or cost considerably more.

An employee wouldn't typically feel comfortable bringing this (personal) problem with their employer, and instead simply ask for a raise without stating that it's to cover the increased costs (after all, this is the employee's problem). But, because they did bring up the root problem, the employer was able to discover it was an issue for many of the employees. They then found it was more cost effective to team up with a local Day Care provider within a few blocks and help provide subsidized Day Care for all the employees within walking distance. It had the benefit of dramatically improving the employees' quality of life, retention, peoductivity, etc. Likewise, it was cheaper than giving everyone raises and not actually solving the root problem.

To the OP, my recommendation would be to think through the fundamental reason why you want a higher salary. There's nothing wrong with wanting more money, and if that's what it is, go for it. But, it means you will likely need to switch jobs. If the raise, however, is a means of trying to fix something else and make you happier, think through what that is and be open to working with your employer to come up with solution together (which might be a raise!).

You may be pleasantly surprised.

I'll prefix my answer with a definition:

adj. meaningless - not bringing a sense of meaning, satisfaction, worth, value, or purpose.

Now onto my response...

I was in AAA video game development, and regardless of what game I worked on, it was always the same thing each cycle: solve the same problems, work long hours on a game I'd never play myself, often detested, and maybe get some kind of a bonus or vacation time if it did well. Rinse and repeat, only each cycle was worse as I got older, had a family, wanted to spend time with them, and learned from past mistakes, but the designers got younger (from my perspective) and wanted to continually make all the same mistakes over again.

After a while, I came across - and read - "What Color Is Your Parachute" (https://www.amazon.com/What-Color-Your-Parachute-2018/dp/039...), which was fantastic!

At the time I was working for Disney and used the strategies I learned to come up with a plan to make connections outside my studio, learn a few new things while helping with other issues. Eventually (it took about a year) it paid off and I was moved + promoted to a completely separate division. I was still helping the game studios, but doing work that was far more rewarding to me and I was learning new skills: big data, ETL pipelines, databases, etc. And, I was able to apply all my existing knowledge and experience to that new position to make it better. I may not know Kafka yet, but I knew how to integrate pipeline code into the game engine using very low memory and CPU.

Time goes on, and - after helping someone else with a Scala + database problem on Reddit, I ended up landing a job using all my new skills at The Broad Institute helping with genetics research. I can't say that I've ever been happier or ever had a job that was more meaningful. I go to conferences now and meet people who are actually using my tools, REST APIs, etc. to cure complex diseases. And I'm learning so much more than I ever thought I would.

Back to your questions:

> Did you have a strategy or was it a leap of faith?

It was a strategy. I think when you're young and don't have a family it's easy to take big risks and leaps of faith. That was not an option for me. But, I think that believing that I _could_ successfully make the transition was a leap of faith.

> Did you regret it later on?

There was one point early on I did. I knew game development inside-out and was an authority on the subject. If I said something in a meeting it was taken seriously. It was hard to go back to being the newbie. After a while, though, that went away. I absolutely do NOT regret it now.

> Are you happy with the decision you made?

Couldn't be happier. Life is better on every single front for me. I'll also note that much of that is intertwined. I'm happy (with work), so I act happier (at home), which means the family is happier (around me), and it all feeds on each other.

> Where do you think you would be today if you had decided to stay in that job?

Do the same shit over and over again, until something happened to the studio and I was let go. Eventually, I'd be a 50-year old game developer that no one would hire because my price tag would be too high, and I wouldn't put up with someone telling me to work 80 hour weeks.

> If you are currently in a job like that, then do you have any plans of escaping to work on your passion?

No.

But, I'll answer this a little differently than you probably expected. At every job I've had - until now - I've always had side projects and little programming things I did for fun at home. I always had an "itch" that wasn't being scratched by my day job. That's no longer the case. I get fulfillment at my job, and if there's ever anything I'd like to explore, I'm lucky enough to be working where it is actively encouraged.

In summary, I'm not sure if your question was a kind of "poll" for something else you're working on or if you are looking for encouragement to escape a job that you find meaningless. Assuming it's the latter, I would suggest reading the book linked - or at least enough to get you going. It has many great tips for helping you discover what's actually important to you, and then how to come up with plans on how to get there. It may take a while, but often, simply having a plan and sticking to it (and being able to see the light at the end of the tunnel) is enough to keep your spirits up.

Good luck!

Just noting that if you're like me and use multiple gmail accounts for personal, work, etc., then I suggest Wavebox.

The Knowledge Portal Network Group at the Broad Institute [0] is looking to hire a senior, front-end, Java/Groovy engineer to maintain, extend, and improve our complex-disease knowledge portals [1]. You can find the complete job listing (and apply) here:

https://broadinstitute.wd1.myworkdayjobs.com/broad_institute...

Our team aggregates and stores statistical data for billions of genetic variants and organizes them to be rapidly queried and visualized by biologists, statistical geneticists, pharmaceutical researchers, and clinicians to find genetic associations, treatment targets, etc. The size of the data we work with is expected to grow by at least an order of magnitude in the coming years.

The current portal code is built on the Spring framework, is primarily coded in Groovy, and makes heavy use of jQuery and D3 for visualizations. Our team also make significant use of Scala. Although not a requirement for this role, if learning and/or using Scala is of interest to you, there will be ample opportunities to do so. We also use Python, R, and some Perl.

You would be working with small team of ~12 people and have a major impact on the future development and directions of the project.

Working remote may be an option for the right candidate (some team members are currently remote). As the Broad is based in Cambridge, MA, there is a requirement that you be within a few hours of EST time-zone, a willingness to travel on-site periodically, and go to various meet-ups/conferences.

This position does not require an immediate working knowledge of genetics, but such knowledge is a plus. The willingness to learn the biology to better serve the computational biologists on the team and better understand the needs of Portal users would be of long-term benefit to the team and yourself. This is much easier on-site as there are constant lectures and learning opportunities at the Broad, MIT, and Harvard for all employees. Some of these are also streamed.

You will also be exposed to several other projects at the Broad which our team collaborates with such as HAIL [2], WDL [3], FireCloud [4], and more.

If you are interested, please apply online via the job posting above. If you have any additional questions, feel free to email myself, Jeffrey Massung, or Mafruha Haque:

jmassung [at] broadinstitute [dot] org mhaque [at] broadinstitute [dot] org

[0]: https://www.broadinstitute.org/diabetes/type-2-diabetes-know... [1]: http://www.type2diabetesgenetics.org/ [2]: https://hail.is/ [3]: https://software.broadinstitute.org/wdl/ [4]: https://software.broadinstitute.org/firecloud/

I picked it more as an example of a company that goes to great lengths to maintain its image and quality. And one which I think reasonable people could understand why they choose to defend that image in court if their products were used in a way that could damage it.

I'm looking at this as though Trader Joe's was a different company... say Disney. Disney goes to great lengths to work out how its products are used, packaged and distributed to not only maximize profits, but also to maintain a certain image.

If I go to DisneyWorld, purchase a Mickey Mouse doll, an take it home. I have the right to do with that doll whatever I want: burn it, give it to my daughter, or resell it at whatever price I see fit.

However, I don't believe I have to right to go - as an agent of another (presumed competitor), purchase that same doll, and then resell it in my own store. I have no resell agreement with Disney to do so. In a typical reseller arrangement, wouldn't a store (e.g. Target) have an agreement with Disney to purchase bulk product for resell, presumably at a reduced price, but also under strict guidelines as to how it could do so? For example: cannot be sold above a certain price, cannot be sold next to adult content, etc.

On a side note: I have to believe that (while not a TJ problem or related to the lawsuit) there were other issues with what Pirate Joe's was doing related to imports, possible tariffs not being adhered to, etc.

/IANAL

Forth is awesome. Simple as that. But it's important for people (especially those just being exposed to it) to completely understand why, and what it's done for everyone.

The indirect threading model was absolutely brilliant. Almost every bytecode VM in existence today owes Forth (and Moore) a giant "thank you." If you never write a lick of Forth code ever, you'll be a better programmer just by researching how its put together.

Forth also pushed for simplicity before it was fashionable. Most "modern" languages pride themselves on their landing-page code samples:

sum = fold (+) 0

But, again, this is old hat for Forth programmers. Languages today use a lot of great, new ideas to accomplish this: FP, pattern matching, closures, etc. But Forth was pushing - back in 1970 - for all functions to "do one thing" succinctly. If it can't be done in one line, you needed to factor the code some more. And, it's not just that the result is one line, it's that _anyone_ can look at it and know what it does instantly. Remember, this was back when BASIC and FORTRAN ruled with GOTO.

Finally, I feel that Forth programmers learn - early on - something I don't see many (very good) programmers learning today: instead of constantly abstracting and obfuscating to try and "simplify" a solution, take a step back and try and simplify the _problem_ so the solution is obvious. For example, this is what I feel the Rust team has done with memory management. Instead of just throwing more brain cells and cycles at trying to improve old-hat solutions, turn the problem upside-down and - in essence - remove it entirely.

Gettysburg The Final Fury by Bruce Catton.

https://www.amazon.com/Gettysburg-Final-Vintage-Civil-Librar...

I'm not much of a reader. I like short, concise, non-fiction, and this was perfect! Highly recommended.

If anyone can recommend similar books for me, please do.

Just a thought: it would be nice if Jarvis could remind someone from my contacts to do something for me...

Jarvis: "X is reminding you to go to buy eggs."

I don't know if you're applying for jobs in the U.S., but here's some thoughts from an American perspective:

* Bullet-point what you actually did as a "Mobile Game Developer". Also, say who you did it for, otherwise I assume it was a side project.

* Instead of listing out to the side every language you're familiar with, note what language you used when you detail what you've done at a job or class project/competition. What you've done in a language is far more compelling than a subjective slider bar that you peg at 100%.

* Since you call out Unity and libGDX, I assume you want to be a game developer. As a long-time veteran of the gaming industry, please add links to side projects you've worked on (even if incomplete), what environments and languages you used, and a webpage with a README that details why you did it, why, and what you learned will give you a serious leg up on all other entry-level candidates.

* Listing every OS that exists in "Other Skills" is a bad idea. An operating system isn't really a "skill". And it's just assumed you can pick up an OS you don't have experience with in a matter of days. The only time this matters is if you have intimate knowledge of an OS (e.g. kernel debugging) or hardware (e.g. LHS optimizations) that would be directly applicable to the job you are applying for.

* Again, the slider bars for "Personal Skills" is a bad idea. This is a lose-lose result for you. "Team Work" isn't pegged? Why not? It makes me wonder in what conditions you aren't good in a team. If it was pegged, then I think you're being dishonest. Remove the whole section. Instead, if you want to note that you're good in a team, tell me somewhere in your work experience or schooling where you worked well in a team and what you did.

* Speaking multiple languages is great! But again, the slider bar is probably a poor way to communicate this effectively. After "Education" have your "Skills" section, and list your languages there.

* I don't know what the "Petnica Science Center" is, but if you graduated from the University, everything else before that doesn't really matter unless they were done in parallel to the university (it's irrelevant that you took a programming class when you were 15).

* Is the "Diploma" in awards similar to a U.S. High School diploma? If so, it's irrelevant as it's assumed by the mere fact that you went to the University.

* Listing the "Honors and Awards" is a great way to stand out. Especially since these were done during your time at the University. Sadly, you don't identify what they are for. What did you do to win the engineering competitions? Do you have a link to a webpage with details of the project? Even if you didn't win, I'd love to know (as an employer) what you did. This is another great place to note if you worked in a team.

* Details matter since you don't have a lot of work experience. I can't stress this enough. If you have a webpage, I want to see it! Put it on there somewhere. Reference it where you can, indicating that more details are available there.

* Be careful about inflating yourself. You do this at the very beginning of your resume with this statement: "I was responsible [for] creating a new custom made 2D game engine in Java using framework called libGDX..." LibGDX already does a whole lot of heavy-lifting. It's like suggesting you made a game engine in Unity. I'm sure you were responsible for wrapping, abstracting, and tailoring libGDX for a specific game and creating gameplay systems, you should be clear and honest about what you did.

* You also gloss over the most interesting part of your entire resume with a single statement: "...implement Facebook, Google Analytics and monetization framework." Each of those should be a bullet point under that work experience with a sentence or two detailing what you did (specifically and briefly).

Good luck to you! And hope this helps!

I absolutely love the mockup. And I agree with most of your analysis. I've felt the same way about the Haskell homepage for quite some time.

Some initial thoughts:

A good recruiter (is that an oxymoron?) will not have much expertise in the field they are recruiting for. Their experience is in their field. However, a good recruiter should have an excellent relationship with the company they represent. Build on that.

Recruiters are akin to realtors. They make their money by putting potential buyers and sellers together and "working their magic" until there is an agreement. They work in qantity, not quality. If you really want to have an impact, fix that.

My experience between recruiters and hiring managers has been that hiring managers don't have a strong ability to convey to the recruiter what's really important and instead toss information at the recruiter that - while technically accurate - isn't beneficial long-term. For example, they may list things like...

- B.S. or 2-year equiv experience

- Be an expert in Python and Django

- Understand how to build REST APIs

- Willing to move to the Bay area

- Excellent communication skills

None of these things actually help the recruiter much. A recruiter will see this and have 4 keys to filter off of in a resume search (BS, Python, Django, REST). And if a prospective candidate is capable of spelling correctly in an email that will be an indication of "excellent communication skills". None of these things will be talked about after the first 10 minutes in an on-site interview. So the recruiter ends up being nothing more than a human-version of a LinkedIn search + initial email.

I like to think that hiring managers are smart, good people who would be much happier with a great Ruby programmer who's never even seen Python, but can identify problems, be pro-active in fixing them, is capable of learning new things and isn't afraid to dive into large, in-place systems, debug, etc. over the candidates that a recruiter would bring them for the above requirements list. But they don't know what list to give the recruiter. Fix this.

Hope this helps.

Don Quixote. I was in HS at the time. Was pretty pissed off at the ending after reading through it all. Looking back, though, I'm glad I read it.

I'd echo many of the things that Arjuna stated. I'd also like to offer some additional thoughts...

Please believe me when I say that your entire world view/focus is going to change over night when your child is born. Your ambitions are going to take a back seat to your child's welfare and stability. But, at the same time, your personal happiness is going to be deeply rooted in your child's.

Are you no longer finding yourself in a "creative" role and instead find yourself in a "support" one? I know when that happens to me initially I have a short period of time where I feel very accomplished and relaxed (i.e. completed project), but then quickly fall into a kind of depression until the next "creative" thing comes up. Before my daughter was born, this was when I would begin looking at other jobs. It wasn't because my current one was bad, but rather because I wasn't being challenged and my skills applied meaningfully. Something new had the potential for learning, creating, and adventure. Years have taught me that very rarely was the problem my environment; it was me not understanding how to pull myself up and start setting goals and being constructive without someone telling me to.

Stop and ask yourself, "if I owned $LARGE_SOFTWARE_CO, and I had a great employee, what would I want him/her to do if they were feeling depressed, unmotivated, and/or bored?" I'd hope your answers would be:

Tell me; I want to do all I can to increase their happiness at work. Maybe there's something I can do to help.... And be pro-active; find where we're falling short and solve it!

After 10 years with a company I have to believe that you've earned some respect. What could be improved? Don't limit your field of view to your own domain. What steps would you take? Go talk to your superiors, tell them how you feel, and give them suggestions on what you (not they) could be doing that would be beneficial to you and the company. Any good manager would be absolutely ecstatic to get this feedback from a valued employee.

Best of luck!

There are several factors here that I haven't seen anyone else bring up yet, so I'll mention them:

1. Negotions will be very different if you need the job rather than "just looking" - especially if they know it. Try not to let emotions get in the way, but it can be tough.

2. Never "negotiate" salary with a recruiter. They make money when you get an offer. They couldn't care less if you get what you want or if the employer will offer you want you need/want.

3. Recruiters don't give a damn about you and they aren't working "for you". You are a commission. They are no different than a realtor. They want to close the deal as quickly as possible and focus on the next commission.

If your first contact with a potential employer is through a recruiter and money comes up, it's 100% about weeding you out. They don't want to waste time with someone who is going to demand more than the employer is willing to pay.

If you don't need the job, your best bet is to talk to them about lifestyle and comfort level instead of money. Do you want to own your own home? type of community? retirement? kids to put through college? The salary required to meet those requirements will be wildly different based on where the company is located, but no matter what the employer's upper limit is you'll know going into the negotiations (later on) that your needs/wants should be met by whatever the final salary agreed upon is. Do not mention what your current situation is. That's completely irrelevant to the discussion.

If you do need the job, and really don't have time to sit around and wait for the best offer possible to come your way, then just tell the recruiter that you'd rather wait until after you've had a chance to go through some of the interview process before talking about money. If they press the issue, suggest that they tell you what the position pays (usually it's a range) and that you'd like to continue forward with the interview. During the downtime, do your due-diligence on the location, cost of living, etc.

Once you're done with the recruiter and through the interview sufficiently enough to start talking real money, it's important (imo) to not worry about trying to squeeze out every dime possible. You should be going into the interview with a number in mind that allows you - and your family - to be comfortable and happy. However, ...

1. Good companies usually have salary ranges fixed based on "level" or some other factors (senior people make X while newbies make Y). Companies that do this have no problem telling you what that salary range is, because they aren't trying to weezle anyone. You should be able to ask them what those ranges are. You should be able to get a sense of what you could be making in the future (but don't count on it!).

2. Remember that benefits can greatly compensate for salary! If the potential employer has a great health package, covers 90%+ of your health care premiums, matches 401K, offers 5+ week vacation, etc. Those things (to you) may be worth far more than an extra $5,000 / year. Remember to give them an opportunity to sell those to you. On the flip-side, if those benefits aren't there, bring those up as part of your negotiation asking for more.

3. This is my own experience, but don't ever take less salary because the company offers great bonuses. It's much better to make $10K more per year than it is to possibly get a $15K bonus at the end of the year. You can invest salary, bonuses aren't guaranteed, bonuses can be taxed differently based on how they are paid out, etc.

HTH

That was my list - almost exactly. Especially Ken Robinson and Dan Pink. +1.

It's not about being hostile/combative or you being too open; it's business.

When a company (or person) asks you to sign a contract, it's an offer presented and written entirely for their benefit. There's no reason at all to attempt to make it "fair" - nor should they. It's your job to take care of your interests and to walk away or push back. Their only interest in trying to make the contract amicable is to seal the deal quickly and/or to not burn bridges.

This is true with everything. If you want to buy a house, the offer you make should be about getting the most for your money. Mentally, you may want to be "decent" with your offer, but that's really just about trying to close the deal quickly before another offer is presented to the seller.

Aside from common things like "being useful" the key aspects of a good API (to me) are:

1. Expose 2. Wrap 3. Consistency

Expose what's going on under-the-hood. For example, an HTTP.Get function may do what's needed 98% of the time, but if you don't expose requests, sending, keep-alive, etc. then I won't be able to do the last 2% when I really need it. Part of exposing is factoring your functions well.

Wrap what's exposed to handle the most common cases. If I want to perform a GET request, I shouldn't be required to create a request, open a socket, issue the request, parse the response, follow redirects, etc. There should just be a simple HTTP.Get function that does all that for me with the common options as arguments.

Finally, the API should be consistent. Consistency covers a range of topics. The API should be consistent within itself: consistent naming, modules, etc. It should be consistent within the environment (e.g. don't use underscored function names in Go). But consistency also means future releases shouldn't break existing code unless absolutely necessary.

FWIW, as a father of a 5-y.o. still remembering the early days, I believe your target audience (for a KS) is really small.

Think of it like this:

My child is born and I come across your KS page. I'm not going to invest because by the time the KS ends and development completes I won't have a perceived need for your product. So, what I really needed was to come across your KS page when my wife was 3-4 months pregnant. Yet, as a would-be first time parent I really had no idea what I would or wouldn't want/need. And after the first child, I'm not feeling the pressure to get and use such an app without a specific concern (e.g. a genetic condition or predisposition to watch out for). There's definitely more fear with the first child.

So, for a KS, your paying audience is a couple (or person) that is 3-4 months pregnant with their first child. That's a very limited audience.

Now, the audience for the app itself is potentially very large. I remember that after my daughter was born going online to find all sorts of information and apps for all sorts of things related to her early days.

My gut says this is just an app that would be much better off ignoring crowdfunding all together. Just make it, list it, and market it. It has a lot of potential. Also, I'd pay attention to what vitovito stated about updates and keeping up momentum as it holds true after release as well.

Paul, this was another good essay.

However, I have to fundamentally disagree with the idea that identity makes one "stupid." When I was a teenager, I had very little in the way of identity, but I was very stupid. :-)

There are many parts of a person's identity. Some are chosen, while others are factual. I can't change who my parents are, what my race is, or where I was born. But they do make up who I am and who you are. We cannot ignore them, and trying to do so causes other problems later in life.

Chosen aspects of one's identity are neither bad nor "stupid." Rather, the reasons people incorporate and cling to certain identities may be, and are the root of the problems you describe.

Example: Atheism vs. Religion.

Electing to identifying with one's self with either of these groups does not [inherently] make one smarter, dumber, stronger, or weaker. What's important is _why_ one chooses to identify with that group.

Does one choose religion to fill a hole in their life or perhaps a fear of death?

If so, then having that identity (hopefully) adds value to, and makes them happier; that's fantastic! But that reason also means when another - opposing identity - challenges their religion, they are threatening that happiness. Defense ensues.

Does one choose atheism in order to feel smarter or to be different/non-conformist?

If so, then when someone with a religious identity tries to talk with them about it, their intellect or uniqueness is suddenly threatened. Defense ensues.

Yet there are many people who have identified themselves as religious, and others as atheist, who are perfectly capable of having very pleasant conversations about life, the universe, and everything, together, for many hours. Why is that? Because their identity wasn't chosen to fill a void, to provide direction, or convince them of something. Instead, it was because that is what made the most sense to them. They are still excited to learn more, and are capable of stating "I don't know [everything]."

Identity is a very _good_ thing. Just be sure you choose your identity for the right reasons.

Jeff M.

Another interesting read. I'd like to note that (while it wasn't the focus of the essay), many of the expensive "checks" aren't there for monetary reasons, but rather human safety and the dire consequences of a poor decision.

Working at Motorola on cell phone code could be a great way to give everyone in the modern world a cool new feature - or accidentally break 20+% of all phones out there. A terrible Mickey Mouse movie could destroy a brand. Take it a step further to NASA, vehicle engine design (and safety), oil pipelining and refining, etc. and the cost could be human lives.

That said, I'm very interested in the cost of these "checks" on those industries. Not monetary costs (although important), but rather the cost in stifled future innovation.

Thoughts?