8 ms·

Philosophies for Software Engineers

79 points by crablar 11y ago

fennecfoxen 11y ago
> Don’t believe the one-size-fits-all interview process with whiteboarding problems. These serve to grind away your individuality and make you feel like an assembly line worker. In my experience, the interview process with whiteboarding problem can go one of two ways. One of them is the "find what we think is the textbook solution to this toy problem" way. The other is the "communicate to us as you attack this toy problem so that we can understand your thought processes, problem-solving approaches, and your experience with these topics" way. Only one of these is really objectionable.
- MCRed 11y ago
  I think both of them are, because none of the problems are really good for explaining your thought process. In fact, it is a contradiction to try and think about a solution to a problem and to give a dissertation on how you're thinking about the problem. You can do one or the other, and in the latter case you have to have solved the problem previously. What I do is ask people about a problem they have solved and get them to teach me about it. If I learn something then it's a good result. Asking people to solve a trivial problem AND let you into the inner workings of their brain-- normally a non-verbal activity- isn't testing their abilities.
  - skybrian 11y ago
    It's not about giving a dissertation. It's about collaborative problem solving. Granted, the interview is rather artificial and considerably more stressful, but you use the same skills when talking about how to solve a tough problem in front of a whiteboard.
  - fennecfoxen 11y ago
    So you nest the toy problem inside a toy system. For instance, instead of just asking people to tell you if someone has won tic-tac-toe (a trivial program-yourself-out-of-a-paper-bag exercise to establish confidence) ask them to design the server side of a client-server tic-tac-toe game. Start with the trivial problem, then move on to all the system design questions that you'll want a software engineer to ask in your system and which require serious communication on a team. (API design for the tic-tac-toe server? Application lifecycle? Scalability? Latency? Take your pick.)
vinceguidry 11y ago
Please don't let things like "Apple makes $1.8MM per employee" get to you. It leads to stupid decision-making. Yes, the company is making more money on your efforts than it is paying you. It's called business, you take inputs and add value to them and sell them to other people who will turn around and do the same thing. If you had capital to throw into a business venture then you'd do it too. I met a guy a few weeks ago who'd moved over from California. He wanted to learn how to code, and told me his story. He was a business sort who went into business with a software developer. The dev did good work, and the business guy managed to get it funded. Just when things started picking up, the dev decided he wasn't getting enough of the pie and bailed, destroying the entire enterprise. He wanted to learn how to code so that this wouldn't happen to him again. So I'm giving him an hour or so a week to show him how web development works so that he can code a prototype himself. Then he can get funded and hire employees rather than deal with the emotional vagaries of software developers. I don't blame him at all. Business guys are typically going to make more money than the coders are, it's pointless to fight this. The better route is to go into business yourself and capture the value yourself. The reason is that the business side is the human side, and humans are harder to deal with, ultimately, than computers are. Also, humans have money and computers do not.
- cheez 11y ago
  Just as much as the business guy wants to avoid the vagaries of a software dev bailing, he's going to have a hard time understanding how good software is created at one hour a week. It was worth it for the business guy to give up a bigger piece of the pie in order to ensure that the business survives. That he is unable to see that, is either because he is unreasonably greedy or short sighted. Now he is delayed for X months or years because he let his greed get the better of him. Once a business is well into money making machine territory, the impact that a single good engineer is going to make is dramatically reduced. At that point, the leverage is much lower and the business person can make decisions like you described.
- _pmf_ 11y ago
  > Just when things started picking up, the dev decided he wasn't getting enough of the pie and bailed This story probably has two sides.
MCRed 11y ago
As an old guy, let me share with you which of these I think was the biggest lesson for me: -- We do not need to be lead by business people. MY new rule for startups - the big engineer should be the CEO. You can have a CTO and other engineers. You can have a VP of bizdev or sales. But the big fish needs to be an engineer if you are a tech company. If you are making biotech the big fish needs to have biotech engineering. If you are manufacturing, then the big fish needs to be a manufacturing engineer. The number one mistake I see startups make (especially when they are started by younger people) is taking some type-A business school graduate and making him the CEO. This is the cause, ultimately, of most of the failures of startups I've experienced (and I've worked for, founded or worked with a couple dozen.) Or, as a second order function, type-A business school graduates who have never started a company or worked a real job but do instead work for a VC firm, forcing bad decisions on your company. Most of the fights between founders are because business guys are forcing bad decisions on the company. The problem is, business school doesn't teach YOUR business. It teaches general business concepts. These are not difficult for engineers to master. IT's impossible for these business guys to master engineering. (Yes, 30 years, still haven't seen that- the best ones just find an engineer they trust and get out of the way.) As an angel investor, if your CEO isn't a geek, I'm not putting my money in. And if you look at the "successes" where this is the case, it's usually an arbitrage opportunity (Eg: somewhere just piling a bunch of money behind a halfway competent business model with half way competent employees is going to make money because the situation is the result of a structural inefficiency, usually caused by government: uber for example.)
- louprado 11y ago
  Agreed. The main problem is you can lie and game the VC's. "It's called future-selling and everyone does it", a biz-guy once told me. It's not a lie, we are "hacking the interview". Coders like hacking, right ? You see, just rebrand "lies", muddle the context and now your type-A biz co-founder can say anything while his engineer co-founder sits their quietly wondering if this really is normal. I've also heard "I'll stop doing that if it makes you uncomfortable" but once it is part of a person's personality, it can become pathological. They don't even know when they are acting this way. The disconnect comes from engineering environments where there is no Alpha and Beta mindset, only varying degrees of competence. Trust your instincts and conscience. The VC only has a limited time for due-diligence.
picrow 11y ago
Typical hippie non-sense from a programmer with an over-inflated ego. Every company is rife with them. 1. You do not have to prove yourself. >> Um, yes, you do. Because you're getting paid to work and work well by people who are risking capital to have you there. You're not entitled to your job. If you feel you should be then move to France and make half the money for the safety of not being able to be fired, or join a sweepers union. 2. You are not a commodity. >> Once again, yes, you are. You are paid to generate profit for the company. If you don't like that then you are free and encouraged to risk your own money on the business of your choosing. Create some jobs yourself. 8. Software engineering is full of lies and people who will try to take advantage of you. >> This is just too easy. Author Jeff just has no real-life experience whatsoever, it seems. 9. You are not your credentials nor your past. >> Then you should go ahead an hire some repeat offenders. Put your money where your mouth is and give a convicted murderer a chance and risk your own money to hire him. You won't. Tl;dr, Author thinks he's special; he's not.
generic_user 11y ago
> 1. You do not have to prove yourself. > Software is a new field and nobody knows how to do it. If someone says you are unqualified and therefore you must do maintenance work, you should question that person. We have an upside down system where the people who are paid the least do the crappiest work. They tend to be young and naive. Software development has been meticulously studied for over 40 years. From Dejurka, 'Goto's considered harmful' to Parnas, 'On the Criteria To Be Used in Decomposing Systems into Modules', Design patterns, academic studies, Pair Programming etc. > 2. You are not a commodity. Your HR department has a list of 'potential hires' to replace any position in your company at a moments notice. The quickest way to build a bad reputation is to think you are not replaceable and act accordingly. > 3. Software engineering is an art and a science but rarely both at once. > The planning and design process is an art, but once the requirements are in place you can proceed more deterministically. No matter how brilliant you architecture and plan is there will inevitably be new requirement or changing requirements that cause you to continuously revise re-architect and re-write large part of your code base. Both design and Implementation are a messy evolving process. > 4. You are not your job. If you do not love this then its not for you. Thats true in many professions and Programming is no different. > 5. The world is a distributed system. I could not parse any overall point to this passage. > 6. You are not a lottery ticket. ??? > 7. Choose action over planning. Talk is cheap and execution is scarce. > This is why nobody cares about your ideas, they care about seeing your prototype. John Mayer said that all he had to do to become successful is finish his songs. Writing a plate of spaghetti code that does some neat thing is not what makes you an employable dependable developer. Writing clean well documented well though out efficient code that meets the specifications is what does that. That take planning and discipline. > 8. Software engineering is full of lies and people who will try to take advantage of you. This is a bit psychotic. > 9. You are not your credentials nor your past. You very much are. You do not necessarily have to be an Academic golden boy but you will be judged by your previous experience and projects. > 10. As a software engineer, you can take career risks aggressively because your downside is fundamentally capped. That works out great unless you have to pay 2500$ rent each month or buy food and clothing for your children etc. Not everyone that writes software is a 19 year old trust fund baby...
- gizi 11y ago
sjclemmy 11y ago
"If we aren’t in control, it doesn’t change anything whether or not we assume that we are in control. But if we are in control, it would be very hazardous to our well being to assume that we are not in control" I love the logic of this argument - it has so many applications - think about applying it to the climate change debate.
- fnovd 11y ago
  https://en.wikipedia.org/wiki/Pascal%27s_Wager https://en.wikipedia.org/wiki/Pascal%27s_Wager The fallacy here is that there is no downside to belief and that finite losses spread over infinite scenarios are still finite. Applied to controlling one's own destiny, the issue is that there is a middle ground between having no control and having complete control. Obviously it is a waste to believe you have no control and to do nothing. It is also a waste to believe you have control of everything: I'm not going to control the weather or other people's moods, so it is a waste of effort to even attempt to do so. The question, then, isn't if we can control our destinies, but how much we can control. Identifying the areas in which your effort would produce a desired effect is paramount. Though of course, due to our population size, you'll always find people who bet it all on black day after day and made that moonshot due to their unfounded yet devoted belief that the universe would unfold the way they wanted it to.
dasil003 11y ago
> After you have spent enough time in the first tier of the intellectual strip mine, we will make you an SDE 2, where you can do slightly higher level refactoring for $150k a year, which will make the giant company $5 million. This is what is called an arbitrage. I've been a programmer my entire career, and so my interests align with this ideology, but quite frankly it is offensive to call junior software dev work an "intellectual strip mine", and to assume a priori that your salary will return 10-20x multiples in value to the company. The reality is that it is highly non-trivial to derive economic value from programming. You have to be able to sell something in significant volumes. That is the value the company is bringing to the software engineer. How much value any particular employee brings to the organization is impossible to calculate. Certainly the engineers will bring efficiencies that are impossible to get any other way, and perhaps they enable the entire business. But you can say the same about the sales people, the biz people, the product people; even the much-maligned marketing people may be essential to keep the revenue flowing. There's a huge bias in any industry to overvalue your own work over that of other disciplines, simply because by definition you know more about it than what those other departments do. There's something I find really off-putting about a lot of abstract whining about how underpaid developers are. Sure, some are underpaid, also some are overpaid NNPPs, but as a whole we are doing way better than the vast majority of careers in the world right now. All this is not by way of saying you should be satisfied with what you're given, but rather that you should pull your head out of the sand and recognize how the world works: you don't get paid what you deserve, you get paid what you negotiate. And negotiation is a skill you have to learn. If you don't want to learn anything about business and you just want to write code, then you should expect to be taken advantage of. If you want to capture more value you create, the first step is defining that value, and you can't do that unless you understand the business. From there you can have honest conversations with your employer on more equal footing, and decide to either stay or leave. This business knowledge will also enable you to start your own company with a much greater chance of success than the majority of startups with purely technical founders who start with a build-it-and-they-will-come mentality.
- gizi 11y ago
  It probably works like that in the corporate world. But then again, most corporations today are pretty much like taxi companies waiting for their own Uber to put them out of business. The company of the future is rather a platform running on the internet. Any company that looks more like a collection of politicking corporate offices instead of an internet platform, is just a dinosaur waiting to get wiped from the face of the earth. The logic and rationale in things like Uber is totally different than what you have described. Uber does not "overvalue" the work of its devs. The essence of what it does, is created by its devs. Furthermore, there are pretty much no other departments in the business. These other departments are all just automated or outsourced distractions. They are not supposed to disturb the core business.
merb 11y ago
11. Make Tests, really. Make automated tests, even if they are slow, make them. trust me. make them regardless what anybody says or regardless the project size. the extra time it takes will outweight the time you would need later.
lorddoig 11y ago
Outright rejection of the fact that life, including your career path, is in part chance-based is dangerous. A sizeable chunk of the part that isn't isn't in your control either, it's controlled by your environment and the people who populate it. If an asteroid struck, and we were all made redundant, you would not have 'lost' - a large example to illustrate a subtle point. Believing otherwise is the kind of self delusion that leads to mid-life crises: when the religion of You crumbles and a desperate scramble for a new faith begins. Life is, in part, a lottery. Failure is fine. Failure is to be expected. Don't read in to it in the context of your self worth, but look at it objectively and see if anything is to be learned. Take risks and accept reality, and never reject the truth, especially when it's staring you right in the face.
JohnLeTigre 11y ago
These are not philosophies.

79 points by crablar 11y ago

> Don’t believe the one-size-fits-all interview process with whiteboarding problems. These serve to grind away your individuality and make you feel like an assembly line worker. In my experience, the interview process with whiteboarding problem can go one of two ways. One of them is the "find what we think is the textbook solution to this toy problem" way. The other is the "communicate to us as you attack this toy problem so that we can understand your thought processes, problem-solving approaches, and your experience with these topics" way. Only one of these is really objectionable.

MCRed 11y ago
I think both of them are, because none of the problems are really good for explaining your thought process. In fact, it is a contradiction to try and think about a solution to a problem and to give a dissertation on how you're thinking about the problem. You can do one or the other, and in the latter case you have to have solved the problem previously. What I do is ask people about a problem they have solved and get them to teach me about it. If I learn something then it's a good result. Asking people to solve a trivial problem AND let you into the inner workings of their brain-- normally a non-verbal activity- isn't testing their abilities.
- skybrian 11y ago
  It's not about giving a dissertation. It's about collaborative problem solving. Granted, the interview is rather artificial and considerably more stressful, but you use the same skills when talking about how to solve a tough problem in front of a whiteboard.
- fennecfoxen 11y ago
  So you nest the toy problem inside a toy system. For instance, instead of just asking people to tell you if someone has won tic-tac-toe (a trivial program-yourself-out-of-a-paper-bag exercise to establish confidence) ask them to design the server side of a client-server tic-tac-toe game. Start with the trivial problem, then move on to all the system design questions that you'll want a software engineer to ask in your system and which require serious communication on a team. (API design for the tic-tac-toe server? Application lifecycle? Scalability? Latency? Take your pick.)

vinceguidry 11y ago

Please don't let things like "Apple makes $1.8MM per employee" get to you. It leads to stupid decision-making. Yes, the company is making more money on your efforts than it is paying you. It's called business, you take inputs and add value to them and sell them to other people who will turn around and do the same thing. If you had capital to throw into a business venture then you'd do it too. I met a guy a few weeks ago who'd moved over from California. He wanted to learn how to code, and told me his story. He was a business sort who went into business with a software developer. The dev did good work, and the business guy managed to get it funded. Just when things started picking up, the dev decided he wasn't getting enough of the pie and bailed, destroying the entire enterprise. He wanted to learn how to code so that this wouldn't happen to him again. So I'm giving him an hour or so a week to show him how web development works so that he can code a prototype himself. Then he can get funded and hire employees rather than deal with the emotional vagaries of software developers. I don't blame him at all. Business guys are typically going to make more money than the coders are, it's pointless to fight this. The better route is to go into business yourself and capture the value yourself. The reason is that the business side is the human side, and humans are harder to deal with, ultimately, than computers are. Also, humans have money and computers do not.

cheez 11y ago
Just as much as the business guy wants to avoid the vagaries of a software dev bailing, he's going to have a hard time understanding how good software is created at one hour a week. It was worth it for the business guy to give up a bigger piece of the pie in order to ensure that the business survives. That he is unable to see that, is either because he is unreasonably greedy or short sighted. Now he is delayed for X months or years because he let his greed get the better of him. Once a business is well into money making machine territory, the impact that a single good engineer is going to make is dramatically reduced. At that point, the leverage is much lower and the business person can make decisions like you described.
_pmf_ 11y ago
> Just when things started picking up, the dev decided he wasn't getting enough of the pie and bailed This story probably has two sides.

MCRed 11y ago

As an old guy, let me share with you which of these I think was the biggest lesson for me: -- We do not need to be lead by business people. MY new rule for startups - the big engineer should be the CEO. You can have a CTO and other engineers. You can have a VP of bizdev or sales. But the big fish needs to be an engineer if you are a tech company. If you are making biotech the big fish needs to have biotech engineering. If you are manufacturing, then the big fish needs to be a manufacturing engineer. The number one mistake I see startups make (especially when they are started by younger people) is taking some type-A business school graduate and making him the CEO. This is the cause, ultimately, of most of the failures of startups I've experienced (and I've worked for, founded or worked with a couple dozen.) Or, as a second order function, type-A business school graduates who have never started a company or worked a real job but do instead work for a VC firm, forcing bad decisions on your company. Most of the fights between founders are because business guys are forcing bad decisions on the company. The problem is, business school doesn't teach YOUR business. It teaches general business concepts. These are not difficult for engineers to master. IT's impossible for these business guys to master engineering. (Yes, 30 years, still haven't seen that- the best ones just find an engineer they trust and get out of the way.) As an angel investor, if your CEO isn't a geek, I'm not putting my money in. And if you look at the "successes" where this is the case, it's usually an arbitrage opportunity (Eg: somewhere just piling a bunch of money behind a halfway competent business model with half way competent employees is going to make money because the situation is the result of a structural inefficiency, usually caused by government: uber for example.)

louprado 11y ago
Agreed. The main problem is you can lie and game the VC's. "It's called future-selling and everyone does it", a biz-guy once told me. It's not a lie, we are "hacking the interview". Coders like hacking, right ? You see, just rebrand "lies", muddle the context and now your type-A biz co-founder can say anything while his engineer co-founder sits their quietly wondering if this really is normal. I've also heard "I'll stop doing that if it makes you uncomfortable" but once it is part of a person's personality, it can become pathological. They don't even know when they are acting this way. The disconnect comes from engineering environments where there is no Alpha and Beta mindset, only varying degrees of competence. Trust your instincts and conscience. The VC only has a limited time for due-diligence.

picrow 11y ago

Typical hippie non-sense from a programmer with an over-inflated ego. Every company is rife with them. 1. You do not have to prove yourself. >> Um, yes, you do. Because you're getting paid to work and work well by people who are risking capital to have you there. You're not entitled to your job. If you feel you should be then move to France and make half the money for the safety of not being able to be fired, or join a sweepers union. 2. You are not a commodity. >> Once again, yes, you are. You are paid to generate profit for the company. If you don't like that then you are free and encouraged to risk your own money on the business of your choosing. Create some jobs yourself. 8. Software engineering is full of lies and people who will try to take advantage of you. >> This is just too easy. Author Jeff just has no real-life experience whatsoever, it seems. 9. You are not your credentials nor your past. >> Then you should go ahead an hire some repeat offenders. Put your money where your mouth is and give a convicted murderer a chance and risk your own money to hire him. You won't. Tl;dr, Author thinks he's special; he's not.

generic_user 11y ago

> 1. You do not have to prove yourself. > Software is a new field and nobody knows how to do it. If someone says you are unqualified and therefore you must do maintenance work, you should question that person. We have an upside down system where the people who are paid the least do the crappiest work. They tend to be young and naive. Software development has been meticulously studied for over 40 years. From Dejurka, 'Goto's considered harmful' to Parnas, 'On the Criteria To Be Used in Decomposing Systems into Modules', Design patterns, academic studies, Pair Programming etc. > 2. You are not a commodity. Your HR department has a list of 'potential hires' to replace any position in your company at a moments notice. The quickest way to build a bad reputation is to think you are not replaceable and act accordingly. > 3. Software engineering is an art and a science but rarely both at once. > The planning and design process is an art, but once the requirements are in place you can proceed more deterministically. No matter how brilliant you architecture and plan is there will inevitably be new requirement or changing requirements that cause you to continuously revise re-architect and re-write large part of your code base. Both design and Implementation are a messy evolving process. > 4. You are not your job. If you do not love this then its not for you. Thats true in many professions and Programming is no different. > 5. The world is a distributed system. I could not parse any overall point to this passage. > 6. You are not a lottery ticket. ??? > 7. Choose action over planning. Talk is cheap and execution is scarce. > This is why nobody cares about your ideas, they care about seeing your prototype. John Mayer said that all he had to do to become successful is finish his songs. Writing a plate of spaghetti code that does some neat thing is not what makes you an employable dependable developer. Writing clean well documented well though out efficient code that meets the specifications is what does that. That take planning and discipline. > 8. Software engineering is full of lies and people who will try to take advantage of you. This is a bit psychotic. > 9. You are not your credentials nor your past. You very much are. You do not necessarily have to be an Academic golden boy but you will be judged by your previous experience and projects. > 10. As a software engineer, you can take career risks aggressively because your downside is fundamentally capped. That works out great unless you have to pay 2500$ rent each month or buy food and clothing for your children etc. Not everyone that writes software is a 19 year old trust fund baby...

gizi 11y ago

sjclemmy 11y ago

"If we aren’t in control, it doesn’t change anything whether or not we assume that we are in control. But if we are in control, it would be very hazardous to our well being to assume that we are not in control" I love the logic of this argument - it has so many applications - think about applying it to the climate change debate.

fnovd 11y ago
https://en.wikipedia.org/wiki/Pascal%27s_Wager https://en.wikipedia.org/wiki/Pascal%27s_Wager The fallacy here is that there is no downside to belief and that finite losses spread over infinite scenarios are still finite. Applied to controlling one's own destiny, the issue is that there is a middle ground between having no control and having complete control. Obviously it is a waste to believe you have no control and to do nothing. It is also a waste to believe you have control of everything: I'm not going to control the weather or other people's moods, so it is a waste of effort to even attempt to do so. The question, then, isn't if we can control our destinies, but how much we can control. Identifying the areas in which your effort would produce a desired effect is paramount. Though of course, due to our population size, you'll always find people who bet it all on black day after day and made that moonshot due to their unfounded yet devoted belief that the universe would unfold the way they wanted it to.

dasil003 11y ago

> After you have spent enough time in the first tier of the intellectual strip mine, we will make you an SDE 2, where you can do slightly higher level refactoring for $150k a year, which will make the giant company $5 million. This is what is called an arbitrage. I've been a programmer my entire career, and so my interests align with this ideology, but quite frankly it is offensive to call junior software dev work an "intellectual strip mine", and to assume a priori that your salary will return 10-20x multiples in value to the company. The reality is that it is highly non-trivial to derive economic value from programming. You have to be able to sell something in significant volumes. That is the value the company is bringing to the software engineer. How much value any particular employee brings to the organization is impossible to calculate. Certainly the engineers will bring efficiencies that are impossible to get any other way, and perhaps they enable the entire business. But you can say the same about the sales people, the biz people, the product people; even the much-maligned marketing people may be essential to keep the revenue flowing. There's a huge bias in any industry to overvalue your own work over that of other disciplines, simply because by definition you know more about it than what those other departments do. There's something I find really off-putting about a lot of abstract whining about how underpaid developers are. Sure, some are underpaid, also some are overpaid NNPPs, but as a whole we are doing way better than the vast majority of careers in the world right now. All this is not by way of saying you should be satisfied with what you're given, but rather that you should pull your head out of the sand and recognize how the world works: you don't get paid what you deserve, you get paid what you negotiate. And negotiation is a skill you have to learn. If you don't want to learn anything about business and you just want to write code, then you should expect to be taken advantage of. If you want to capture more value you create, the first step is defining that value, and you can't do that unless you understand the business. From there you can have honest conversations with your employer on more equal footing, and decide to either stay or leave. This business knowledge will also enable you to start your own company with a much greater chance of success than the majority of startups with purely technical founders who start with a build-it-and-they-will-come mentality.

gizi 11y ago
It probably works like that in the corporate world. But then again, most corporations today are pretty much like taxi companies waiting for their own Uber to put them out of business. The company of the future is rather a platform running on the internet. Any company that looks more like a collection of politicking corporate offices instead of an internet platform, is just a dinosaur waiting to get wiped from the face of the earth. The logic and rationale in things like Uber is totally different than what you have described. Uber does not "overvalue" the work of its devs. The essence of what it does, is created by its devs. Furthermore, there are pretty much no other departments in the business. These other departments are all just automated or outsourced distractions. They are not supposed to disturb the core business.

merb 11y ago

11. Make Tests, really. Make automated tests, even if they are slow, make them. trust me. make them regardless what anybody says or regardless the project size. the extra time it takes will outweight the time you would need later.

lorddoig 11y ago

Outright rejection of the fact that life, including your career path, is in part chance-based is dangerous. A sizeable chunk of the part that isn't isn't in your control either, it's controlled by your environment and the people who populate it. If an asteroid struck, and we were all made redundant, you would not have 'lost' - a large example to illustrate a subtle point. Believing otherwise is the kind of self delusion that leads to mid-life crises: when the religion of You crumbles and a desperate scramble for a new faith begins. Life is, in part, a lottery. Failure is fine. Failure is to be expected. Don't read in to it in the context of your self worth, but look at it objectively and see if anything is to be learned. Take risks and accept reality, and never reject the truth, especially when it's staring you right in the face.

JohnLeTigre 11y ago

These are not philosophies.