That said, with two years of experience, I'd think it more important to meet others in your field. A friend who can get you past HR is more valuable than another line on a resume.
What's even better are the websites that they host their streams on are constantly changing names since they keep getting taken down, or throttled but the templates the websites use are exactly the same: the type of embedded video players, the font, format, etc. The only thing they change is the color and the name.
But yes banning a domain name is possible, or ICE can take it down but that only applies to American websites.
It's impossible for websites to be taken down but it is possible to limit their exposure and that is to have an American version of the great firewall, but that'll never happen, hopefully...
I spent an absurd amount of time trying to figure out how to let multiple instances of the browser operate concurrently without affecting each other. E.g., if a resource request is in progress, then a second request to the same resource simply uses the output of the first (which is a problem if it's stateful output for the user).
After reading most of the JavaFX and WebKit codebases I realized that isolation is not possible without recompiling a modified WebKit. So then I set about figuring out how to isolate Java code. But most solutions are half-baked, are only academic research projects, or require a special JVM.
However, if you load JavaFX along with native libs into a classloader for each browser instance, then they're effectively isolated. The downside is that objects of the same class have completely different un-castable types if they're from different classloaders.
So then I needed to use reflection to lookup classnames at runtime and resolve them dynamically.
From your description, it sounds like these programmers are not as efficient in their work, or as task/goal-oriented as you'd like them to be, but not that they're completely incapable. Sometimes you will find programmers who can't program; they're hopeless, you have to fire them. But otherwise good programmers can be awful at managing themselves... and you're the manager, after all, so it's your problem to solve. Of course, you don't want to micro-manage them every hour of the day; that's not scalable.
Not every aspect of Extreme Programming is applicable to every situation. But a quick morning standup meeting can be a very effective tool. First, you will find out when people get off track and are having problems. Second, it creates some accountability to advance the ball every day. Third, while you must actively work to have the team cooperate instead of compete, it will naturally create some competitive and evolutionary pressure, where the more focused members of your team provide a good example and, over time, can share some of their secrets. Finally, the standup helps reinforce teamwork. If someone is having a hard time with a task, you can respond and say, "hey, you know, Bob's in a good place with what he's working on, why doesn't he help you out today, see whether a fresh perspective can help?"
A daily meeting/checkin is super valuable but don't expect your junior devs to pipe up with what's actually important. You may have to check in with them one-on-one, in private, to hear what's actually on their minds. And ask specific questions, not just "how's it going?"
-accept that different folks work at different speeds, measure success on dollars made or saved -- real business metrics -- not are they fast vs your expectations-share the end goal and business metrics, don't 'task' people, give the a mental stake in the real problem -- otherwise you are not getting their brains, just their hands-if you have a strong preference for hands off and not guiding, hire for that, which is a longer chat but I can share how I do it-if you are willing to have 'dependent' developers, personally pair with them and see the real problem in real time, not a weekly or daily vignette
Do you have regular one on ones with them to shoot the breeze about what they're working on? Find out what motivates them. Maybe they don't believe in the work going on and think the lead/manager (aka you) is just giving them busy work. Explain the broader picture of what their contributions mean to the organization. Did they get "passed over" for the role you now have?
If you work in a big company, maybe they have seen where getting work done quickly doesn't get them ahead. Maybe there isn't any room for them to grow. What do they want to be when they grow up?
When assigning work, ask them about their approach to the task. Ask them to ask their coworkers or bounce ideas off them. Maybe they think building VM's will help with testing for future work.
You may not be their HR manager (hire, fire, raises, etc.) but talking with them about non-task related stuff may enlighten you with how to better work together.
* Low competence, high commitment -- these guys don't know wtf they're doing, but they're happy to be there. They need direction and guidance, very hands-on. The strategy here is "I talk, I decide."
* Low competence, low commitment -- these guys don't know enough to work on their own (but maybe aren't totally incompetent), and they're discouraged. They need direction AND encouragement. The strategy here is "We talk, I decide."
* High competence, low commitment -- these guys know what they're doing and can work on their own, but maybe they're bored or intimidated or not confident enough to really take charge of their own schedules. They need encouragement and advice. The strategy here is "We talk, you decide."
* High competence, high commitment -- these are the ones where you say "Here's a problem, go solve it". The risk here is that they'll leave -- they don't need you anymore, right? The strategy here is "I trust you, you decide, but I'm here for advice if you need it."
That's just a really rough overview, but I suggest picking up some management books. Like my boss tells me, "if you're trying, you're one step ahead of the game."
- Untimely completion of core tasks. There may need to be more frequent check-ins with more granular goals, along with accountability or at least retrospection for missed checkpoints. If a checkpoint is missed, the dev and you have to figure out the why of it and how the process can be improved in the next iteration.
- Lack of resourcefulness/grit. This can be taught. This is where it helps to pair someone with a strong developer or yourself. As a teacher, we modeled the learning process as I-do, we-do, you-do. It may be enlightening for an unproductive dev to see better habits in action. But you can't just show a skill and hope it will be replicated. You have to gradually shift more responsibility to the other party to transfer the knowledge.
- Misspent time. Not every subproject is useful for its own sake. Hold your team members accountable for demonstrating the value of tangential work beforehand, and put your foot down if you're not convinced. Everyone loves a side-project, but it's not a substitute for progress on the core goals.
Most people want to improve, but everyone has some mixture of compentencies where they will naturally self-improve and ones for which they will need mentorship. This isn't the sort of thing where you can make one exasperated speech and see overnight improvement. The goal should be gradual, consistent increases in productivity.
And don't forget, since just became a team lead, you also need guidance and continuous feedback. Be proactive in seeking it. Good luck!
As a lead is your job to put them on the right track, so you should try to understand their way of thinking and weak points.
If even after trying hard you still can't get them to perform properly, let them go. It might be that they're too "scatterbrained" or that you weren't able to find the right way to approach them, but, either way, if you've been through, it doesn't really matter.
YMMV, but the point is: you're the one supposed to 'bend' more to make the collaboration work. If you can't, you still should try to solve the situation (for the sake of all parties involved, not only yours) by letting them go, having them reassigned, or something else.
The paper's basic tenet is that managers, by over-focusing on "poor performers", actually cause their poor performance by interfering with their work and putting them on performance improvement plans. Are there measurable differences between these people and your high performers in terms of output, or are you simply observing that to be so?
And listen to jonstewart. Being a manager is very different from being a programmer. Be humble and introspective, and work on becoming better at your craft.
Many developers get sidetracked because they are afraid to confront the fact that they don't know how to do something. Make it clear that it's okay not to know something but it's not okay to just avoid a task in front of them. Find roles for them where they can excel. Imagine being a coach of a basketball team. Some players are good shooters while others might be good at defense and rebounding. It's up to you to find these strengths and use them together. A fast developer may get excited about doing new development but hate doing things they consider grudge work. These slower developers might like doing work like testing and documentation (and actually be better at it).
You may try pair programming. Might decrease productivity but increase quality. Or you can find another way of getting help from the two good guys like you on keeping an eye on them.
Whatever you do, a team of five is quite small. Just keep close to your team, move to a single room together, share a long desk with them etc. You may also want to divide work into smaller chunks so you can keep a better and timely track.
I've worked with someone who had a reputation (previously unbeknownst to me) of being terrible to work with and inadequate to the task. However, I both enjoyed working with then and saw them make significant strides in understanding in less than a year. What was the difference?
* I made a point of working with them until they understood the problem at hand (easier to do as a fellow developer than as a manager, though, I suspect). This had the side benefit of often increasing my own depth of explicit understanding.
* I would rewrite code that they found confusing until it made sense to them. I also emphasized (sincerely) that their lack of understanding was an asset we could leverage to engineer more inherently clear code.
* Every bug of theirs was a learning opportunity.
* Praise for accomplishments, even small, was liberal.
All of the above might sound excessive and like "hand-holding," but it's things that everyone needs. A lot of us just lucked into receiving such reinforcement earlier in life, or were spared the negative reinforcement that can only be undone with larger doses of the positive. The more you invest in the "problem" developers now, the higher the dividends later.
Hoping that advice helps, and let me know if it does!
Your environment is get things out the door fast sort of environment? Doesn't mean their bad, just different values.
Should have worked out their values at interview stage.
In a different company they could be the stars, and your the guy close to being fired.
Letting go of someone is the simplest thing anyone can do... but if you look back at your own career, chances are you'll find more than a couple of instances when your peers put up, tolerated, and coached you to where you are today - just don't close the doors you walked through.
You also introduce targets for them to achieve. Tell them what you want them to do, and ask them to focus on which-ever bit you think they need to focus on.
Do they know that you aren't happy with their performance? How early in the process do you catch it and correct the action? It doesn't sound like it's very early at all if it's a week later and they are coming back at with the same questions.
I'm not saying to micro manage or even tell them that they are poor employees -- I believe both approaches lead to hostile work environments. The best managers I ever had largely followed the principles laid out in How to Win Friends and Influence People, and now that I'm transitioning to leading small teams I find that approach leads to far better results than the alternative.
I managed to fix this by getting a new job where I didn't have to manage. ;)
1. The circle of trust starts big and shrinks every time you fuck me. All of my staff are aware of this. Aware of my expectations and it rarely requires a personnel meeting. I don't micro-manage unless I'm forced into it by someone's behaviour or performance.
2. Managing a team of devs is no different than coaching a sports team. You have varying levels of talent, ambition and inter-personal skills. The trick is to find the best fit for "players" where they feel they're contributing and others don't resent them for "messing up". Once you do that you can develop them.
As a team lead it is your responsibility to your staff, and the company, to develop those individuals. I guarantee treating staff like people instead of widgets pays in the long run. With that being said, sometimes a team member doesn't see acknowledge a lack of skill, etc... and they have to be let go.
2. You must have your finger on the pulse of everything going on all the time. Not every little detail, but you must know where each project is, plus or minus 10%. Don't let yourself lose track of anything; that's when problems start.
3. Reviews must be daily, not weekly. You don't need status meetings, emails, or project updates, just one minute reviews. 3 day old problems are 2 days too old.
4. Peer review everything your people do until you're absolutely certain you can let someone else do it. And even then, continue to peer review something they do every week. You are responsible for their work; peer review is one of the best ways to stay one top of it, insure quality, and teach. And always be brutally honest with peer review, never bashful. Tell them what's not good enough, what you want, and why. It may be uncomfortable at first, but it will save everyone headaches later.
5. Read "The One Minute Manager". Then do it.
6. Be nice, have fun, and get shit done.
Recognize that you're new to management. As a new manager the overwhelming odds are that you suck at it in ways that make the dictionary definition of "suck" say, "No really bro, that's not me."
Nothing personal. And even if I am totally incorrect and you are the immaculately conceived management prodigy, the best attitude you can have is that you totally suck and that the team goes home after work and tells their spouse dogs children and parents about the idiocy they deal with because of you.
If people are coming back a week later and demonstrating that they didn't understand last week's conversation that's an indication of less than effective communication on your part.  Never mind getting people to do what needs to be done, they're not even getting the what of it. A lost week means you haven't followed up.
To put it another way, how you would do it doesn't matter. You're just another snowflake. What matters is getting it done in the ways the people who you want to get it done will do it.
Favoring your doppelgangers means that other people's diversity prohibits them from ever being any good as far as you're concerned. You're the new boss and you're broadcasting closed mindedness. To the degree it's about who will tow the line and who won't.
It happens all the time. The PHB is a latent talent in everyone.
 And very effective communication to. You are effective at communicating "I don't think you are very good." And It flows as naturally as the title of this Ask HN. It's disrespectful and counterproductive.
I just know that the most important management skill is 1) to make the decision to fire somebody and to do this not too late and 2) then to execute it smooth and fast. And most managers are neither good at 1 or at 2 because of lacking practice.
It's a though decision, it doesn't feel good to fire somebody and often managers ask themselves if they made mistakes in their leadership.
But if you say that you just don't feel good how they do their work and if you don't see any potential for improvement then why don't you spend the budget for better engineers?
"Protect, direct and eject." You need to protect your top performers from the political conflicts that high performance attracts. You need to direct the people in the middle or those who haven't found a way to shine yet. We won't talk about ejecting, because you haven't made a case for that yet.
Middle management presents a weird conflict of interest. You're still judged on deliverables rather than intangibles (like an actual executive) but you're going to have to take interest in your reports' careers if you want to have credibility with them. You have to be a product manager (to get X done for some "X" that is larger than you can do yourself) and a people manager, and to manage up.
There's no silver bullet, but I think you need to humanize yourself and the relationship. You don't want your developers to see you as "The Boss", and you have to take interest in their careers and help them get where they're trying to go (which may be off your team, for the two who don't seem engaged). The difficulty of this depends both on your interpersonal skills and your credibility within the organization. Ultimately, if your managers (up the chain into the executive suite) don't care about your reports' careers and advancement, it's going to be a struggle to get for your reports the support and resources that they'll need to be motivated again. If your managers are bad, it's just a losing battle for you.
Ultimately, you're going to have to figure out what your reports (all 4 of them; don't just focus on the 2 who seem to be lagging) want and make sure they get it, and that they know they will have your support as long as they don't betray your trust. Then you need to come up with a strategy that meets your project-management targets but also engages them. That's not an easy thing to do and it's impossible to come up with a general-purpose solution.
See also this oldie article: Don't Let Architecture Astronauts Scare You http://www.joelonsoftware.com/articles/fog0000000018.html
Sometimes people have good ideas that may be a little overkill for your project. Running a VM could help with creating test environments. Although there may be alternatives to that. So maybe they just want to test more. Maybe they are more QA types.
Try to understand where they are coming from and give them some guidance. :-)
The less good programmers probably don't know how to evaluate what's important and so waste time. For them you'll need to dive down one level: "we need to drain this swamp, so go evaluate pumps and if you find one with X liters/minute for less than $Y, go install it on the north side." For the other you might need even more detail. Part of the art is picking the right level of detail so you aren't wasting a lot of time and so hopefully the recipient can learn from it.
If you have to dive down TOO low you have the wrong people.
And your managers: I hope they are eliminating uncertainty too: We need to get rid of the "mosquitos so get this swamp drained by the end of the month. You have $Z to spend on it."
1. Maybe they are not in the mindset of getting to the goal, but rather they are in the mindset that work is work. Or maybe they are doing it simply because it's a habit or because it's fashionable and they heard some celebrity say you should use a VM. Then explain to them that not all work is equal, and that it's important to do work that moves you in the direction of the goal, rather than busywork that will not pay off such as setting up a VM envirnoment.
2. Maybe they actually think that setting up a VM environment is worth it in the long term. If you don't think that is the case, explain why.
3. Maybe they don't know how to solve the problems that they are tasked to solve, and setting up elaborate dev environments is a way to procrastinate. Then make sure that they have enough guidance so that they know what concrete bit of work they can do right now to make actual progress. Ex: if they don't know how to make progress because they do not understand the database schema, then the next step should be to familiarize themselves with the database schema. You could even task them with writing documentation for the database schema to get this started. Or perhaps they procrastinate because they don't like the work that is assigned to them.
There could be many other reasons, but once you figure out why they are doing this, it's likely that the solution will be relatively obvious. Try to not fall into the trap of micromanaging them. If you don't understand why they are doing this you could simply instruct them not to set up a VM dev environment. That won't solve anything in the long term because they will just find something else. It's much better if they know why they should do or should not do a that, rather than simply following orders. Following orders kills motivation and orders don't generalize to new situations, but the right mindset does.
On the other hand, in some cases the issue isn't that a developer is not doing the right kind of work, but rather that the developer is doing the right kind of work but he is simply not very good at it. This can be improved to some degree with training but you have to make a business trade off here: is this developer making a net positive contribution to the business or not. Keep in mind that a developer does not have to be super productive in order to make a positive contribution. Otherwise it's time to move him to a different role or fire him.
Only wanted to say, that I've learned a lot from the answers presented here... Some of them made me really upset (as in my blood boiled), because I recognized some patterns as ones used by my old managers. The "make them do estimates" and "Make the penalty for missing their own deadline big" part is what I immediately recognized as the most often occurring one.
Nevertheless, there are some very fine tips which I will try to use in my personal time & task management. I see immediate benefits, even tough I have nothing to do with management role at all.
Secondly, I see a bunch of people suggesting you micromanage these people and I must advise you that nothing good can come from this. You need speak with and make your self available to people daily or several times a day but you MUST give them space to accomplish something on their own.
Thirdly, you must set expectations and required outcomes. You can only set expectations if you know the clear path from A to Z and if that isn't the case, you need to trust your employees when deadlines slip. You need to manage the expectations of your customers so that there is a wide buffer between when you expect employees to get it done, and when you expect to deliver to your customers.
Your inefficient employees aren't dumb. They know their peers are outperforming them. It is your job to provide a safe stable work environment where employees can relax when there is a lul, and strive for greatness when there is a deadline. You can not work your employees to death.
"Teach them to be better than you. That may seem counterproductive. I have a type A personality, and I have decent coding skills. I've been in your situation a number of times. I also know there's these mythical expert developers out there that I can't seem to find (or afford). So, what to do? A few years ago I realized that if I continue down this path, I'll end up with some serious health issues due to the stresses that come along with having a reputation for being a really good developer.
So, I decided that instead of searching for developers better than me, I would teach developers I work with how to BE better. It's taken a lot of patience. And it's taken me quite a bit to LET GO of my way of doing things. I had to take my ego out of the picture. (VERY hard to do.)
Nowadays, I realize that developers don't have to BE better than me. I simply have to ALLOW them to do what they do without being so obsessive about it. Turns out, even junior developers really CAN do good work. They just need a little guidance that only comes with experience, and then they need me to get out of their way."
Set up to fail: How bosses create their own poor performershttp://www.insead.edu/facultyresearch/research/doc.cfm?did=4...
"I like how it describes the negatively reinforcing cycle of closer scrunity which results in worse performance etc. " -lifebeyondlife
They're all individuals with their own interests, motivations, self-purpose. You have to understand who each of them are and how they all work together. Then, you must question if the issues are innate or only symptoms of something else.
Most likely (since they're hired and not fired) they're all able. So, are they bored, burned out, tired? Are they not being rewarded for their work? Do they not understand the high-level goals? Are you micromanaging? Do they not understand their roles? Roles are important - it must be completely clear that they have a singular set of roles and responsibilities.
Sometimes it's ok to have inefficiencies with one or more staff if it benefits the whole system. For instance, I kept a guy on my team simply because he was funny. He made the other teammates laugh and have a good time.
The idea is to make them part of their own reformation:
- Don't set deadlines, make them set deadlines, document it, then hold them to it. Make the penalty for missing their own deadline big. Because you've documented it, if they make a pattern of missing their deadlines, work with them on learning to better gauge and estimate their level of effort. Review the cases where they miss the deadline, find out why, build up a pattern. It could be they just don't understand how some library works, or how the build tools work etc. It could be an external dependency they have no control over. Either data-point gives you tools to help them learn how to do this most basic of tasks.
- If you tell them something once, and they come back again, the second time make them write it down in a binder of notes, if they come back again, make them refer to their own notes. If they come back yet again, make them do a full report on the topic, put it on an internal wiki, and treat it like a High School writing assignment. It sucks for them so they'll never want to do that again, but it produces useful information for other people.
- Don't tell them what to do. But make them describe their strategy to tackle the task. When it sounds like they're doing something wrongheaded, ask them why they're doing it that way instead of the obviously better way. Maybe they have a good reason, maybe it's out of ignorance. Take it as an opportunity to make better ways available to them. But the decision for which way to go is up to them, so long as they hit their self-imposed deadline.
Accept that developers are a diverse set, mostly self-taught, and all have varying degrees of expertise. In order to find the people you'd like, sit down and define what an "ideal developer" looks like (irrespective of whether you're actively hiring). That way you can either hire people that match that description, or work to build up your existing team to match that.
It sounds like your first step is to document your process and to educate your development team on how to do things "your way," and why you do it that way.
I think smart, experienced engineers who have been figuring everything out on their own for a while start a totally new role, then forget how to ask for help when needed.
I was like them. I've been programming for over 15 years. I started when I was a kid. When I started programming as a profession, I kept the same habits I had when I was doing it for fun. Ie, find hard new stuff I've never done and learn how to do it! I was inventing new problems to solve because I enjoyed learning new things. Unfortunately this isn't a good model for generating money for a smaller company, you don't yet a lot done if you keep task jumping around. When I started to make a list of things to do I could refer to it and ask myself If the task I Wanted to work on was actually necessary.
Also, don't overload them with stuff to do. Before I if someone had a request for a change I would switch in the middle of a task and try and complete it. This goes back to the todo list, you learn to focus on one thing at a time.
When you are repeatedly asked the same question, ask yourself why? It is probably because you failed to answer adequately the question that was asked.
If they have less domain knowledge, they will be slower on technical tasks regardless of ability.
You as the lead should be providing the information your developers need to get the job down. Sounds to me like you are acting like and egotistical developer IC, rather than a team lead. You could probably find a way to help them if you tried...
1. It takes time, be patient
2. Get under people and push them up. Instead of standing over them and pulling them up. What's the difference ? In the first you are saying "I'm not too good too grab someones foot and boost them up", in the second you are saying " I have arrived now I'm going to drag up to my level of greatness".
3. Sometimes people are distracted and slow because they are a square peg being jammed into a round hole. Not every programmer thrives in the same environment, you have to tailor your management and help style for each individual.
Or perhaps not; idk...no one here can, but it is your job to figure it out, quick. Use the same tenacity you showed as a developer to start learning management.
The daily stand-ups are a no brainer...accountability and progress need to be applied and shown, respectively, with consequences attached, unless you are happy to let things ride along as they are currently.
It sounds like you need to manage them by breaking their tasks down into more bite sized chunks if you don't want them to go off task.
Our experience is this makes each team member pick tasks that fit their strengths, or challenge themselves. You, as a team lead, can leave them along to handle it. They will ask for help, or mention they are stuck in the daily stand-up.
EDIT: I guess I didn't need to be that blunt, thanks downvoters for pointing that out.
How can I stop this behaviour? It's like I'm not in control, I just get carried along by the current.
One big problem of big companies, is hiring developers who actually cant even write a simple algorithm. Cranck up your hiring process to ensure only the good developers are hired.
I've dealt with people like that. You explain something to them 5 times and they still don't get it. Some people just don't have the talent. The previous lead probably didn't notice or care.
Did you speak with your bosses about replacing them?
Even if the team lead is just being narrowminded, those two devs would be better off working with someone else.
I'm a lead as well and one of our developers is a smart but scatterbrained programmer. She is a mess in terms of running a project and communicating with the rest of the company but if I give her a specific task, she does well.
So what I did was insert myself in any meeting she was a part of, and talked with her several times a day to check in. When I see her going off course in a meeting, I will correct it, and if she says anything incomprehensible in a meeting, I will translate for the others.
The good thing about this programmer is that she really wants to improve, so I give her very frank feedback. The feedbsck I orovide is along the lines of "you need to increase people's confidence in you, because right now it is low, we don't know if you can run a project on your own". She has gotten much better and a lot more productive, which I honestly believe is due to me. I don't take any credit for the work she does, and I constantly praise her in front of others, but I do know that without my micromanagement, she would not be nearly as productive as she is right now.
If her productivity didn't imorove with my micromanagement, I would have fired her because the last thing we need is a drag on the team due to an unproductive member.
It makes sense to use virtualization, but you should also have a standard build that uses tools like Vagrant.
If a developer has to spend more than an hour to set up a development your process is broken by modern standards.
i bet the 2 fast developers and yourself never cared about unit tests. leaving the people that don't want to write temporary test cases completely lost. they probably sake their head every time they look at the code base, try to start to sanitize it, realize it will take forever now, give up in the middle, and end up just contributing to the mess.
First, focus on fundamentals. Spend time with the guys who are having trouble getting stuff done. Pair program with them, letting them drive. Or pair them up with one of the people who do work well.
Second, create effort estimates. No, really. Sit down and have these guys explain to you what they will do and estimate the amount of time. Tally it up as you go, then double it, telling them you want a margin of error (make sure to double it again when speaking to your boss, but don't tell the developers that). Encourage them to speak with you immediately if they run into problems that will derail the estimate. This exercise will help a lot in terms of getting them to understand what they really should be doing.
Third, don't be a micromanager. Assign a task, support them and check in periodically, but don't push them to do things a certain way. I am really not a fan of the standing morning meeting. Instead, talk to them individually for 5 minutes every morning. It's more of a pain, but it's less stressful on them, which is good. At the same time, encourage them to talk to each other and do have an occasional team meeting (a quick one) explaining where you are heading.
Fourth, forget about programming. Sadly, you won't have time for it. With a team this size, you might still have some time, but it's best to lower your expectations dramatically. You'll be doing quite a bit more thrashing between different tasks aimed at supporting your team. You know work for them, and your job is to keep them focused and productive. This really means two things: (a) don't take on large or important projects or projects with major deadlines, and (b) don't seize control of the system architecture. Why? Because you won't have time for it, and will block the rest of the team while you do the research.
Fifth, and this is somewhat in conflict with #4, the buck stops with you. Example: my team wanted to switch from using Django's built-in template system for Jinja2 without any real need to do so (we made very light use of the templates anyways; their argument was more of a preference). I listened, but ultimately said no. We had much bigger fish to fry, and this would have been a costly distraction with no upside. This was not a popular move, but the issue was let go after a few weeks.
Sixth, be honest with everyone about how things are going. If the devs are not pulling their weight, encourage them to get better. Offer help, guidance, etc. If they don't improve, consider letting them go. If you are a team lead, chances are you don't have that power, but surely your boss will want to know that the company is paying good money to the people who don't do the work required.
Lastly, remember, as the lead, it's your job to move the furniture out of the way for your team to get shit done. Your priorities have shifted, and now you are in a different role. The sooner you adapt to that mode, the better.
P.S.: Take vacations, and often. Burnout sets in twice as fast for team leads.
1. Concrete, quantifiable goals. The first time I really ran into a wall with my issues prioritizing was during summer CS research after my sophomore year of college. I was given vague tasks that were basically "make the program better." This doesn't help someone that is prone to tangents. In the process of working on some part of the program I might discover a new thing that needed fixing, switch to working on that, and then down the crazy refactor rabbit hole.
2. Deadlines. Deadlines help a lot (as annoying as they are). I always did well in school because of deadlines. At my work we have a goal of completing X% of Q1's weekly sprints on time. It's a team goal, so if I don't get my tasks finished for the week, the whole team doesn't get clear the sprint for that week. I find the team aspect helpful. It also facilitates communication between team members. People that finish early often look at the sprint and check on members that aren't done yet, offering assistance.
3. Boredom. Boredom is a real issue for me. I do better on harder tasks than easy ones because they're interesting. This isn't something I think a manager can solve because I think it's on the programmer's end to learn how to do work when it's less-than-engaging. But you might find some of your scatterbrained programmers actually tackle hard problems better than easy ones. It really depends on the programmer.
4. Communication. I was pretty upfront with my manager about prioritization and focus issues. It's something we discuss every time we have a one-on-one meeting. How things are going, what strategies I'm using, etc. He's also great at pruning down my conceptions of tasks. I'll read a task and think, "Oh I need to get X, Y, and Z done" and he'll say, "No, you just need X, the task doesn't actually call for Y and Z."
5. The optimization struggle. This is probably the single largest contributing factor to my prioritization issues. I don't like doing things a way, I like doing them The Best Way. A lot of time is spent figuring out which way is The Best Way. I might waste several hours working out a linear time solution to something I could easily write polynomially all the while n is small and it doesn't really matter. Inelegant code bothers the hell out of me so I might start a small refactor which snowballs into a larger and larger refactor. This is something that your programmers will have to get a grip on--saying no to refactors in order to better focus on a task. But as a manager you can help by watching out for tangental refactors and putting a stop to them.
My feeling, especially when starting with a new group of people, is the amount of time you should allow them to struggle is inversely proportional to their years of experience.
In the end productivity is important, but not at the expense of creating a hostile work environment. Programmers need to be ok with creating imperfect things. Sometimes it's the only way they'll successfully iterate toward creating less imperfect things.
Another interesting thing about managing programmers is it's difficult to create objective metrics by which to assess performance, which you can then easily compare to other members of the team. In other words, I can't go find the box and say "why is that box still over here? I thought I told you to put it on the other side of the warehouse?". or "Why is that pasta not in the boiling water?" At best I've only ever had a clear "sense" of where each member of the team is. Nothing I can put on a chart that shows definitively that Team Member A is performing at a higher standard than Team Member B. In this case it's critical to give the slower guys the easier tasks, and the more ambitious guys the bigger tasks.
Create a tighter feedback loop for those who you see as having difficulties. And create opportunities for people to collaborate, and in the process compare themselves to others on the team. And every once in a while sit with them while they're working for maybe 15 minutes at a time. Don't expect them to do things your way, but by the end of the session offer a few suggestions. And make sure they set goals for themselves. "How long do you think it will take you to finish that?". Make a note of their goal. And then when the time is up ask them "So have you been able to finish that?" If not, what's wrong, and how can we help you? If so, then good job let's move on to the next thing. And I saw in other posts the suggestion that sometimes you should break down the tasks into smaller more digestible chunks instead of having them do that. Great suggestion.
Finally, it's not an infallible metric (and in fact probably not a good measure for anything performance-related), but lines of code committed is I feel a good "BS detector". I had a guy (arguably senior, and arguably unmotivated) on a team I managed a while back who managed to commit less than 100 lines of code in a month. That's as close to an "obvious sign" that something is wrong as you will probably ever see. Writing code is what programmers are paid to do, so if they're not doing it there's no way to assess their performance.
When you do it long enough, you get a really good sense of the structure of programs. Then, it's just a matter of fitting in the best technologies of the time into the 'architecture'.
The full stack is just data storage, data transfer, processing, user interface, system structure, tools, and processes. When you do it long enough, you get a good, general understanding of all of these pieces.
When I take on a new project, I do the following:
1. learn about all the 'current' technologies
2. write simple apps (full stack) in each of them
3. decide on which are best (sometimes I make mistakes, often I use 'old' stuff)
4. cram a bit
5. write a somewhat more complex app
6. learn the rest, as I go
Wordpress? Just another CMS.
Joomla? Just another CMS.
JSON? Just another interchange format.
Just do what you can, and don't beat yourself up over what you can't.
What I'm getting at is that MOST of the time, even if a particular job lists off some particular tech, the ultimate customer is generally interested in a good working solution and doesn't care that much about the tech used.
The secret to doing full stack development well is figuring out how to keep the number of things you need to know at any given time low. A product that is using Ember, React, Angular, PHP, Python, Scala, Postgres, Redis and MongoDB is going to be hell on the developers. The developers (and the product) would likely benefit from some serious triage work. Get rid of half your middle languages and half your databases, because they are redundant and doing so will make your life easier. Great engineering depends very much on deciding what you can get rid of.
How this relates to freelance work, I couldn't tell ya. By hopping from project to project it seems like you're going to be exposed to a mind numbing number of technologies. Sounds like fun actually, but it's a different animal from full-stack development. Most of the successful freelancers I've met focus on a particular technology. E.g. Mongo contracts out experts in their database, some people specialize in search technology, others do HBase. Nobody does all of those things at the same time.
I find it's pretty important to know the kind of thing (what it does, the 1000ft view, the basics of the area that it's attacking) and then the differences between the (generally guaranteed to exist) alternatives/other products that do the exact same thing.
Databases - You should know what a database is. How have people done databases in the last 50 years? 40? 30? 20? 10? now? (while that seems like a lot of research, it's generally not - as much as some things change, a lot have not changed for a long time in CS). What are the big theories that propel most of the solutions? ( for databases you might find stuff like mmap, b-trees, indexing, hashing)
Then, there is the question of what is the difference between Postgres & MySQL? MSSQL & Oracle? RBDMS & NoSQL? RethinkDB/Mongo & Neo4J?
I generally find that knowing stuff in those frames is more than enough. Personally, this approach works but I am embarrassed when I have to look up things like "how to list all the tables in mysql" on Google, but I'm starting to think that's not such a big deal. Yes, I don't know every oracle/microsoft/mysql/postgres command, but I think it would be more ridiculous to take the time to try hard to memorize stuff like that, and then completely miss out on the benefits of NoSQL databases, for example.
Also -- do tons of side projects.
I got real burn out with front end, with emberjs, angularjs, and now react. I'm going to just wait this out until ES6 come about and see where that go.
I think in general I moved toward back end with all the big data and data science is going to be at. And now I'm going back to school to become a data science practicioner.
The trick is to have enough experiences and understanding overall concepts. I've done a variety of MVC in different languages and was thrust upon to do frontend and all that jazz. Those experiences will help you solve problem easier and hone your skill set in finding solutions.
I've seen people talking about how full stack is unicorn. I'm a full stack, I'm experienced in many technologies, master of none but a very small subset. I am constantly surprise how I am way more qualified than some of those frontend programmers or architecturers out there.
The deal is just continue to gain experiences on variety and you'll hone your problem solving skill. You might also be under selling yourself too. There are very few engineers out there and there are tons of pretenders. I've worked with two "front end" and a "acting cto" that specialized in architecture. They were anything but the position they claim to be but they sure do have a purrty linkedin profile with tons of people writing good things about them.
The only things that have really helped:
Key takeaways go into a Deck in Anki (spaced repetition).
Lots of notes and/or screenshots in Google Docs for easy searches. (still haven't embraced Evernote)
Bookmarks in Firefox with tags.
Teach someone what you just learned.
One frustration in particular is the time spent wading through minutiae instead of creating something with impact. But sometimes that's part of what we get paid for, navigating / remedying the pain points. Anyone can (eventually) slog through most development technologies, but adding understanding and context and utility to it, that's where the challenge lies.
Heinlein said something to the effect of "specialization is for insects," but increasingly the bulk of world seems to be leaning that way. There's nothing wrong with specialization, but choose wisely. Check out Google Trends on a few technologies over the past 10 years and see their rise and fall.
HN is the only site I visit for tech news. The rest of the news I get through newsletters. I follow about 20ish, which I sift through each week to stay updated.
Now it is important to note that theory will never make you an immediate expert at every language and platform. However, it does let you bootstrap yourself into a language or framework quickly enough that outsiders will hardly be able to tell the difference.
I've found that once I understand the flow of a program, and ideally the theory driving that flow as well, the syntax required to express the changes you want to make to the flow is merely a few Google searches away.
Another thing to note, if you bounce around like this, you will never get true mastery over a particular language or framework. This is OK for more than 80% of the work you do, but you will end up picking up more information about one language over another - of one framework over another - simply to complete your work. Having this depth of knowledge is not even remotely a bad thing, so long as you keep sight of the bigger picture: don't let the quirks of one language or framework constrain your thinking for all languages.
Re-learning a framework/tool is usually pretty easy.
Most of the new techs are fraud like angular; like in science a new tech should be something that simplifies the world with a simplified view : a map.
A map should always be simpler than the stuff you want to describe. Angular for instance is kind of the string theory of JS development; formalism is complex, it makes a lockin for incompetent devs but it brings nothing new.
But still, I can do angular fairly well, because I like to rant, and it is funnier to rub your despise into people's face when you outsmart them.
Computer language when you had to learn thousands of words to be understood and complex grammars for foreign languages are freaking easy; python is around 50 core words. Perl 300 ...
Most of what computer science are proud of is scam. No critical thinking and no building up of intuition makes people looks like headless chicken yelling new tech, new tech and bumping into each other.
Me on the other hand, I can guess where the flow of circuitry will bring the data into memory, if their will be localisation if the L1, L2 cache will be used. I can feel the unstability of the sequencer with page fault or OOP missing.
Because computer is still a dumb automata that is part of my formation; I learnt how to build microchips.
But electronics also learns you how to face complexity.
You don't see the world bottom up or top down. You are like a go player. You embrace the world's complexity by building up 2 pictures of complexity one for the bottom the other for the top and you try to make them converge in the middle.
high level abstractions like CSS and files (yes a file that has the open/read/write/seek/tell/close/ioctl is an abstraction, it does not exists on the silicium level) requires to be careful. But still they are never new. They are built up on other layers of abstraction (geometry for CSS)
Some abstractions are insanely more complex than the world they describe (CSS). Happily for me I learnt Tk/Tcl that gave the packing geometry understanding (the so called boxing model).
Angular is shit, but I learnt xmlhttppartialrequest a long time ago, so I know how to circumvent this horror.
I can quote a lot of example where focusing on the basics on the core of knowledge (what does the GIL do, how to bind on a library with python, who does the PCI bus works) finally makes you outsmart the competition of the stupid devs throwing themselves in new technology in the hope they can cut corners.
There is no lazyness possible. Computer programming requires a lot of knowledge, rather focus on learning the basics : - what is an OS (especially POSIX);- network programming;- algorithm;- CPU architecture;- a tinge of ASM;- bus specification;- memory allocation;- physics (only physicists understand why distributed MUST not use timestamps or any global clock and why acausal events might occures);- math: linear algebrae, proba and especially geometry (yep even for CSS);- theory of measure;- signal processing and the theory of dectection of errors
When you have the basics, no frameworks or new technology are either intimidating or out of grasp.
Most of the so called new techs are fraud.
If a map is not simpler and as accurate as the world it tries to describe, then throw it away. That's how I deal with new techs; by discarding most of them.
Warning:Strong, controversial, personal opinions ahead.YMMV.
I'm not a "Full stack developer", believe that that is nota good goal, and, thus, don't want to try to be one.
Instead, I'm just trying to make money with, yes, acareer.
In a restaurant analogy, I want tobe good as a chef and open and run afinancially successful restaurant. Maybe I want to open a pizza shop, an Italian red sauce place, a highend northern Italian placewith $100 Barolo wines, a French bistro,a French provincial place, a French nouveaucusine place, a French classic heute cuisineplace with $1000+ bottles ofRomanee Conti, an American steak house, e.g., 18 ouncedry aged Porterhouse steaks, a Memphis choppedpork shoulder and rib BBQ place, an American diner,an American fried chick shack,an American hot dog and fries shack,an English fish and chips shop,an American NE seafood bar,a family Mexican place, or something fromKorea, China, Viet Nam, Japan, ....
I wantsome one of those and certainly not all of them.I need to be a good chef for the one I want,not a full stack chef for all of them. Beinga full stack chef for all of them isunnecessary and hopeless and, thus, foolish.
Then in computing, I want to know what I needto know for my business; learningeverything about computing or just softwareon Windows, Linux, mobile, embedded, etc. is unnecessary and hopeless and, thus,foolish. No thanks.
So, in particular, I'm not trying tocirculate my resume as a full stackdeveloper, able to walk into just anyold software for any old project,hit the ground running, fully understandeverything being used right away, like being able to walk into justany kitchen of any restaurant and cookanything on the menu, right away,etc. and to be a do it all employee of someoneelse who is the founder, CEO of the businessand himself knows much less.
If sucha CEO wants a full stack developer, thenhe is asking for too much, really forsomething next to impossible, as thequestion of the OP correctly implies.
Also full stack developer comes close tobeing an insult for everyone who doesn'tknow everything. But since the goal ofknowing everything about software isessentially impossible-- won't find chaired professors ofcomputer science trying to do that --the insult is really on the CEOasking for the impossible.
Really, I've decided that I should bea founder, yes, very much a technicalfounder, so far a solo founder,and not an employee. Then as a founder,my real interest is in my business,not the full stack.
Actually,I want to minimize what I learn, not maximize it. Or,in the restaurant analogy,assuming I want to openan Italian red sauce place,I want to know well everything Ineed for that restaurant andlikely with nothing aboutMemphis BBQ, Japanese sushi,Chinese dim sum,etc.And even in that Italianrestaurant, I may be theback of the house guyand leave the front of thehouse to a partner oremployee. And I willsubcontract linen service,kitchen design andconstruction,dining room decoration,etc. Similarly for mybusiness based onsoftware.
Net, to heck with the full stackand, instead, concentrate on thebusiness and there learnwhat need to know, maybe learnthat quite well, butdon't try to learnthings don't need andcertainly don't try to learneverything.
Really for my business, the crucialparts are(1) the problem I'm trying to solve,a problem faced by essentially everyuser of the Web in the world,(2) some crucial core, originalmath I derived to be thesecret sauce for an especiallypowerful, valuable solution to theproblem,(3) some initial data,(4) publicity,(5) server farm and networkmanagement and security,and (6) the correspondingsoftware which, given (1) -- (5),is supposed to be just routine.
In more detail,I decided to build on Windows instead ofLinux, so I am usingVisual Basic .NET, .NET Framework4.0,ASP.NET (Active Server Pages or some such, object library forthe server software to build Web pages),ADO.NET (Active Data Objects, objectlibrary for using SQL Server),IIS (Internet Information Server,for the lower level parts ofthe Web site),SQL Server,TCP/IP, and system management and security.That's about it. Already thedocumentation I have is5000+ Web pages and abouta cubic foot of books --not trivial.
E.g., for my Web site session stateserver, I set aside Redis andjust wrote a little codeusing TCP/IP, class instancede/serialization, and two instancesof a collection class -- easierthan just understanding Redis.For communications betweenseparate server side programs,I am using just somesimple TCP/IP andclass instance de/serialization --it's simple and is working fineand was much less work towrite than just readingMicrosoft's documentationof some of their softwareto make such communications easy.
So, to heck with the full stack and,instead, on with my business.
If my business works, then I will haveto hire, but I will never try tohire any full stack people. Instead I will hire forability to (1) write clearly,especially software documentation,(2) communicate clearly with others,especially in a team,(3) read, understand, and applytechnical material,(4) have good new ideas andmake them real,(5) work hard,(6) be honest,(7) know at least the basicsof computer usage.For the rest, I will train.
This is your opportunity to plan, when you are back to busy you will appreciate what you have worked up.
I wish I could be so lucky to attract senior candidates at my current gig; they're hard to come by at a trendy downtown-SF mobile commerce pre-series-A startup. Instead, I'm inundated with fresh code-bootcamp graduates. I'd be much more comfortable hiring those junior developers if I knew they would be able to sit next to a reliable senior teammate...
That said, if you're worried about being hired, start by building something on your own! You'll make yourself much more marketable if you show that you can pick up new technologies and actually release something.
Agreed, it seems outside the cultural bubble of the Bay Area the entire technical workforce seems to be aging. I see fewer and fewer of the younger generations entering tech outside of a few markets like the Bay Area and Austin.
I have a theory, that it is due to the work force being more mobile, as well as the younger work force having less to tie them down. There was also, consolidation of the start-up markets and a lot of other markets lost ground while the Bay Area gained. I think this creates a natural draw for the younger portions of our workforce.
Most of the individuals I run across outside of a few specific markets are mid-30's to mid 50's and age seems to be a less relevant factor.
I'm already starting to be concerned about age discrimination, and I'm only 40 years old! It's very disturbing when you go on an interview and you're the oldest person there by 10+ years.
The only way out is to start your own business. Do you have enough savings? If you do, consider trying to bootstrap your own thing instead of going back to being an employee.
Also, outside of SF, the ageism is much much milder. I've had people who had the up/down control on me getting hired not know my age to within 15 years at the time they make that choice (and they consistently guessed _older_ than I am). But interviews in SF seem to bring this topic to the table almost immediately. YMMV.
In terms of being uniquely identifiable (and therefore having few secrets) in the job application process, this is essentially unavoidable. I wouldn't worry about it.
With 40 years of programming (not sure how many were hobby vs paid), you are likely to raise questions as to how many more years you would need to work. You can trim the appearance of some years off to get in the door and avoid the possibility of discrimination.
The fact that you are on HN and able to have this kind of insight proves you are capable of hanging with the youngins.
Some younger engineers will worry if older engineers lost their hunger for learning new technologies. In their position, they are well aware of what is fashionable, or even just current best practice. This is mostly because as new people they go straight to the new stuff. For example, new programmers don't learn SVN, they go straight to git, and github is a way of life.
So, right or wrong, it is a red flag to them if they see or hear about people advocating what they consider as outdated approaches.
But, importantly, they also read books by the folks who are 20-30 years older, but never lost that drive. They go to talks by these people and take notes, buy their screencasts, and brag about what they learned. They want luminaries to guide them. So, maybe, establishing expertise over what they consider important is a way around this misconception the youth has.
I imagine you could send positive signals by fixing or improving some popular open source project. Maybe write some interesting toy code, a game, or something that solves a development problem, and add that to a personal site or your github account. Any way to demonstrate what someone with 40 years experience can do, in a context they can see and interact with should do the trick.
We have found that one of the biggest factors in getting employment offers is how you position yourself. For instance right now if you are an enterprise engineer with extensive perl or .Net experience this will hurt you if you want to get into a young web company. On the other hand if you are an iOS or Node engineer in SF or can position yourself as an engineering manager then you're likely to find it easier to get job offers.
In general, the data that I've seen suggests that new companies are basically not interested in older technologies. I believe that the problem a lot of older engineers have is that they try to enter the current market by relying on their old skills and that mis-match is interpreted as ageism.
In my experience having experience (and age) is very valuable IF you're a strong engineer and you can apply that experience to the existing technology landscape. Make sure that you're presenting yourself to the right companies with skills in the right technologies and toolsets though or they will not even look at you.
On the other hand, as others have stated, you better avoid making your age obvious.
In the end, you know what? In this life your time is limited and I think it's wise to avoid worrying about things you can't control. Don't make your age obvious but have confidence in your skills and experience!
It probably depends on the job description, but sometimes more experienced candidates get rejected for this exact reason.
I'd love to hear how other people handle this type of situation.
My parents, born in the mid-1950s are currently in the job market looking for work, and they claim they feel the ageism/discrimination but it completely baffles me as a younger person.
As a person who celebrated Y2K in public school, now in the workforce blazing my own trail: I personally wouldnt have any issue with your age whatsoever. I gauge people based on results and performance, and so if you're an old dog I dont need to teach you any new tricks, you're probably a pro already!
I would be a little intimidated by your age, and it would be humbling and awkward for me to feel like you were my subordinate, but I would cherish your insight and experience (and hopefully mature reasoning skills) and I believe you may have a lot to offer!
I still prepare resumes and cover letters for my parents as they hunt for jobs, and I wish I could encourage you as well.
Age != youth
Age != ability
Age == how many pages have been turned in the 'Book of You'
Best of luck as you put yourself out there!
Okay, I'm lucky to be at a point where I squeezed enough blood from the software development rock to carry on even if I never wrote another line of code again.
But I can hardly express how much happier I've been in a (relative to "rock star" and/or "ninja" mindsets) silly, part time "data specialist" position for a local non-profit that really needs someone who can spin useful utilities and disparate systems connectivity from any available silk (or dirty kite string) than I've ever been slaving away in the usual "headless chickens" environments managed by the usual clowns whose management training consisted of little more than proving themselves useless at software development itself - which training, of course, tends to result in the aforementioned hiring prowess to boot.
Good bleeping riddance!
Secondly, my advice is to do nothing special. Yes, filter your resume for things you think the company would be interested in -- you would do that regardless of your age. In general a one-pager resume is greatly appreciated by everyone. If it comes up that you've been around the block more than most, fine. You don't want to work for companies that would discriminate against you based on age anyway -- they are probably going to fail due to stupidity like not appreciating expertise learned from experience.
Why would you want to work somewhere that allows or encourages discrimination on age or anything else?
Let assholes filter themselves out of your life.
I admit that if I was faced with the opportunity of hiring someone a lot older and experienced than me I'd have two immediate thoughts: "This guy would be a great asset, we need him" and "I think I'd be way too intimidated and nervous being his boss, can't do it".
Doing consulting work solves the second question since it changes the boss-employee dynamic to a more business-to-business like one.
Now, I am not in a position to hire anyone so take my introspection with a grain of salt.
2. Don't be paranoid but don't play it up.
3. There's no way to hide your age, realistically. You have to answer questions like the year you graduated from college, the year of your first job.
4. There are a bunch of people that age I would kill to work with (35 year programmer), we have half a dozen people in our office with that much experience. We're a C shop and we write very, very high performance code. WORK YOUR FRIENDS, you must have friends, those friends have jobs.
Instead of being 59 you will be 49? I don't think it will help. Instead, put a spin on it and sell yourself as experienced in technical matters.
My spouse worked jobs with on call for many years. Though not in tech the disruption came from being on call not the nature of the work.
I'll add that the reason it gets rotated could be either it pays so well that it's only fair or it sucks so much it's only fair.
Some of the suggestions based on my experience:
1. Make sure there are enough team members are in on-call rotation so that you get your 1 week on-call every 6 to 8 weeks or more. If on-call is too frequent, it will be disruptive to your normal life and you and your family will resent the job.
2. If your on-call only requires remote phone/access support, make sure company picks the tab for your phone and mobile internet. If, like mine, on-call requires onsite visit, company is properly compensating for mileage and auto-expense. Also get company to pay for on-call either in cash or with time-off. You can also work these out informally within your team and boss. My company paid for my cell service, home internet, and provided auto allowance.
3. You should have a place in your house where you can quickly go, talk, and work in the middle of the night without disturbing rest of the family.
4. Make sure your team and boss are okay with you coming to work late or skipping days coming to office when you are on-call and receive calls in the middle of night. My worse on-calls used to be woken up between 2:00 - 4:00 AM when I was typically in deep sleep.
5. Avoid scheduling anything important during the on-call week. And, let everyone know that you may have drop everything else if you receive a call.
6. During the on-call week relax, don't take too much stress, don't do too much of regular work, don't force yourself to have a normal day-and-night, go with the flow.
7. Avoid going to places like movie theater where you can't take phone call and quickly get out of.
8. Don't get anxious during on-call week. I had co-workers who used to have panic attack during the on-call week.
HOWEVER: Is management dedicated to making sure those issues are rare? Namely:
1) Do they give you the time and leeway to fix technical debt that causes these things to pop up?
2) Are there reliable code review, continuous integration, and QA processes that ensure that fewer bugs make it to production in the first place?
3) Is it easy to roll-back a deployment at 2am on a Saturday?
4) Is there a well-maintained schedule of IT and development changes, with impact assessments, so that people don't page you during a downtime they should've known about? And so that, after a failure, you can view historical data and determine the causes of a failure and effectively develop a plan for mitigating it in the future?
5) Can YOU page the DBAs at 2am on a Saturday when you need their help? Are they going to be rude when they call you back, or are they going to recognize that the health of the systems is their job, too?
6) Do devs willingly, openly own up to the bugs in their code, in front of their bosses, without fear of serious reprimand? Does the company recognize that mistakes are inevitable and that process and communication are better than blame-finding for preventing failures?
The answers to all of these questions (and more) will, directly or indirectly, indicate the frequency and overall stress of carrying a pager for a given company. (They're good questions regardless of pager duty, too.)
In my experience it wasn't really the actual notifications and weird work hours that was the problem. The problem was that I was officially the end of the "it's someone else's problem" chain. It's a funny thing about moral hazards and shit rolling downhill: there's always someone at the bottom. If you're on pager duty, you're at the bottom.
So I liked feeling trusted with an important task and I liked ensuring that other people could sleep. But the pager came to represent every wrong thing with everything in the world. I stared at it in revulsion by the end of things. (Yes, I had an actual pager to stare at.)
That's just my personality, though. Your mileage will vary.
1. First of all, it will get you connected to the users which depend on your $APP/$SYS. Hard. You will get to know their struggle/woes - it's not just some ticket you can work on at your leisure.
2. If it's your stuff that causes problems, you will get your shit together and make sure that it works, code defensively, and test thoroughly - whatever necessary. After all, you don't want to deprive yourself unnecessarily of sleep or others, after the experience.
3. If it's not your stuff that causes problems, you'll get the oppurtunity to yell at the people responsible for it. And they must act on it - nobody cares on the why or what, if people have to get up in the middle of the night, it costs the company, and everybody gets upset.
It only impacts your health if you get called up regularly, and no actions are taken to remove the root causes of it. Or you can't take any.
It's less of a technical problem, but more an organizational one, so as it already has been said in here you should talk to the people of the team, not HN.
) If it doesn't cost them, be wary.
I have had good and bad experiences, but it really depends on how bugs are handled by the organization and do you have to wait on other people during the night.
I've worked at one place where any bug that triggered a page was unwelcome and fixed first and quickly. It was considered unacceptable to wake anyone and a possible problem to staff in the morning.
I've also worked at a place where management did not really seem to care when people had to be up every night of a pager rotation because of errors in the system. They wouldn't even prioritize bugs that would let people sleep through the night. It was hell and affects your attitude about everything. Also, the DBA team didn't exactly answer their pager in a timely manner which lead to some very dumb things.
I see the only value in going through pager rotation to learn how code correctness is important.
Hardware failures are a different story. Only thing I ever get paged about at my current job is that the power went out or the air conditioner in the server room broke.
Carrying the duty pager is a painful experience for some fraction of companies, BUT the long term trends are promising. Here's what I'd keep an eye out for (I've been on call for ~5 years):
* Does being on call affect your other commitments? At PD we scale back the number of predicted story points by ~50 for the devs that are on call.
* Are you empowered to permanently fix the root cause of whatever woke you up? (that's where that 50% of time goes) If you aren't, that's a big red flag. Not all developers take advantage of it, but the ones that do are much happier once they kill the root cause with fire.
* Are you compensated for on call? Among our customers, we have a few that pay $500/week for on call duty, that seems to be the rate at which you can easily find people to swap shifts with.
* Make sure you are off call sometimes. Seriously.
* Who owns the pain report? Someone needs to track how often (and when) people are disturbed and make sure that you are making progress as a team (Github's Ops team is amazingly good at this). If the house is always on fire, you're not a firefighter, you're a person who lives in a flaming house.
* Is it a NOC model, where you can write down common things to try to solve a type of problem (and then you're only paged as an exception) or are you paged for everything? (That's a severe over simplification)
* What is the expected response time? What is the required response time?
* How are you onboarded? The worst time ever to fix a problem is alone, with no context, while things are broken at 2am.
That's off the top of my head; there's good advice in this thread. if you're still lost though, feel free to reach out to me: email@example.com
Edit: I should also add one last thing. If you are knowledge industry professional, is working part-time graveyard shift something you spent all that time developing your skills for?
I've yet to find a company that doesn't abuse it to save money. Unless I own the company or have a significant share I no longer agree to help the bottom line by messing with my health.
I might have had bad experiences compared to most but since you're thinking about this option, wouldn't it make sense to think about why the company hasn't just shifted an existing resource to 2nd/3rd shift to help versus trying to save money by making you do another job on top of your day job?
Good luck with the switch!
1. Six people rotation. You need to put your personal life on hold for the duration of pager duty, make it as spaced out as possible.
2. The person on-duty had veto power over any deployment past 3pm in the afternoon.
2.b The person on-duty had veto power over any deployment on Fridays (24x7 means pager duty last the whole weekend).
3. Every person in the roll was a developer familiar with the systems. We had first responders - spread across timezones doing "follow the sun" scheme - taking care of the simple stuff, but when push come to shove, you need qualified people at the wheel.
On the other hand, I have done horrible shift work. While each situation is different, there are two common themes: Lack of proper training and understaffed team. The very worst of all was when management tried to solve the later inflicted the former upon two unrelated teams that found themselves having to support systems they knew almost nothing about. I don't know what was worse, the utter feeling of panic that came with every ticket of the other system, or the quiet despair of coming to office on Monday morning and finding out what sort of chaos had spawned out of your under-qualified peer's meddling.
Would you say it's an interesting experience to go through? Yes. You will appreciate good code, frameworks and systems that seldom send pager notifications.
My personal preference is to rotate weekends and weekdays within a team. That way someones entire 7 day week isn't impacted by being on call.
Really, you should ask the people on this new team, not HN.
The amount of escalations obviously varies from week to week. Some weeks I forget that I'm even on call (well that's actually not true as we have to carry a Lumia 1520 - the thing is a fucking brick) while other weeks are absolutely painful (waking up every couple hours in the middle of the night). Thankfully we have enough developers on the team that I'm only on duty every 6 to 7 weeks. What also helps is that my manager has no problem with me sleeping in and showing up late after a long night of escalations. Overall it isn't too bad and in fact sometimes can be fun to solve head scratching issues. Honestly, the worst part of being on call is not being able to make plans that would involve you being far away from a computer. You can turn this into a somewhat positive thing though by being productive at home whether it is cleaning, working on side projects etc.
Everything stated below about disruptions to your personal life are true. When you're on-call, you should just forget about personal commitments. When personal commitments unavoidably collide with on-call, you're at the mercy of kind teammates swapping with you.
A good team will cover you the next day if you had a bad night, but I think during every bad night, a little part of you has to say "f### this job" and given enough bad nights, well... I'm a single dad w/ a kiddo, and I can tell you there is nothing worse in life than reading a kid his bedtime story, having the pager go off in the middle of it, and having to say "sorry, son," as he begins to cry and say "not again, Daddy!" (True, and awful story.) Like I said, "f### this job."
Anyway, a funny point about devops/fix-your-shit is that there's an effect here which parallels the Peter principle (getting promoted to your level of incompetence) in some ways:
If you fix everything that causes you to get paged, then eventually the only things that page you are things you can't fix (the network, power event, etc). And while those kinds of wake-ups at least lack the adrenaline/stress component (just sit there and wait for recovery), they further reinforce the "f### this job" thoughts - because now you're literally being woken up for no reason other than to "observe and report."
In my case, I ran a startup for a few years which was quite profitable, but was set up in such a way that I often had to drop anything else I was doing and rush to respond to the service being down, at any time of day... In addition to already having more than enough to do between programming, sysadmin work and customer service.
Being up adjusting to a change in a data providers JSON or figuring out why MySQL is cripplingly more slow all of a sudden at 3:30 am isn't a pleasant experience, especially if you also have to be up again at 9 am.
In our case, there was little to do about it as the service provider we depended upon for almost everything frequently surprised us with breaking changes or temporary bugs. That led me to find the entire affair rather stressful.
So, like everyone else is saying... Depends on how often you're paged, and whether you have any influence over the root cause of the errors you're being summoned to fix.
I think you should ask the developers in the other team how often they get called during their rotation. You should also ask how much of a priority it is within their work scope to eliminate the issues that are causing the processes to fail.
I used to work for a small company that had nightly batch processing jobs on stock data from that trading day. If any one of those processes failed, then someone had to log in and fix it or the company wouldn't have a product for the next day. During the day we had other things to work on, things the business wanted and there was little importance given to fixing the brittle (broken) data processing. Management saw it as working software. They weren't the ones logging in at 3am for two hours to keep the business rolling the next day. That had a big effect on me. I felt like they didn't care about building good software, testing the software, and giving the developers peace of mind that what was in production was well tested and signed off. This is what ultimately led me to leaving that company and joining one which had solid processes: development -> staging -> qa -> production. Because of that process we haven't had a single outage in 3 years. I can go home at night and think about the software I'm currently building, not worrying if I'm going to get an email alert late at night because no one cares about fixing our broken software/processes.
In conclusion, take heed.
I remember my first page was on the day before Thanksgiving around 5PM. And then the 2nd and 3rd one one came after that around 8PM adn 11PM. And then on Thanksgiving day I got paged around 9AM when I was driving to the airport to pick up my brother. I didn't know what to do at that point.
The worst happened when my wife gave birth and I got paged while waiting in the hospital. She gave birth 2 weeks earlier so it screwed up my on-call planning. I called my manager and said "you gotta get someone to replace me, I am at the hospital."
About 6 months later I quit.
Yes, this was a problem with insufficient logging. However, when you have a platform used internally by dozens of other teams, it's nigh impossible to ensure that all of those teams are logging and handling errors sufficiently well to ensure that the platform team gets paged for only platform errors.
- Will you get any form of compensation if you have to work after hours?
Where I worked - that was a no. You were paid industry minimum and when you were on call - you were expected to be alert/on call 24/7 AND come in and do your normal 8+ hour shift. Now - I don't mean a 1-1 level of compensation but at least be flexible especially if you were on call.
The calls themselves weren't usually bad - but if you have to come in on a weekend anything you planned on over the weekend is now shot and that can be extremely stressful.
When we did it, the response times and time on the clock were clearly specified. Return the call/page within one hour between 8AM to 11PM. Later we scaled it back to 7PM and then finally to support only during normal working hours.
Whoever got the phone that week also got a small bonus for doing it to reflect the inconvenience of having to respond to calls on personal time. On average there was rarely a support call outside working hours so it really wasn't a big deal.
But I think it depends on your personality too. It just didn't sit well with me but it might for you. Just my 2 cents.
If the software and tema are small enough for you to have an affect on it -- this becomes a motivation to make sure things seldom go wrong enough to result in a page.
Since then I've taken a fairly laissez-faire attitude to being on call. I'll pick up notifications on an as available, best effort basis. That means if I'm around and get an alert, I'll do my best to resolve the issue right away. However, if I'm with friends, my phone will be in my jacket pocket hanging in a closet somewhere while I might be drinking and I'll see any alerts when I'm leaving for the night. That could be many, many hours later. I make no effort to restrict my activities so that I'm always around. And if I leave my phone on vibrate and don't pick up any alerts while I enjoy a sound night's sleep, so be it.
If "as available, best effort" on my part isn't good enough, then the company will need to compensate me appropriately for the interruption that comes from a higher level of commitment. Some physicians get $100/day and cardiologists get up to $1600/day to be on call as they need to limit their plans and avoid activities which make them unavailable.
In a nutshell, if getting paged at all hours of the day and night and having quick responses to issues is important enough then the company needs to pay for your time, lifestyle interruption, and mental energy at a rate you think is fair. I suggest a minimum daily/weekly/monthly rate based on making yourself available plus hourly compensation for the actual time you put in at a 1.5x or 2x hourly rate. This all goes out the window if you're in some scrappy underfunded startup, but if you're employed in a company which has graduated from shoestring budgets and has paying customers and decent revenue then you should be getting something for what is effectively overtime.
1) When you're oncall, your time and priorities are no longer your own.
At your kid's soccer game? A date night? Planning on doing any of those things? Be prepared to get pulled out at any moment to deal with something that could take hours to resolve. This was the part that really got to me. As much as I'd like to do any one of those example things, I had made a prior commitment to be available and had to honor that.
2) Know the response time and physical location requirements for responding to a page
Is this something you can just fire up your laptop and an aircard and jam on, or do you have to be able to drive to the office within an hour. Don't forget about driving through places with less than great cell phone coverage.
3) It can be fun
There was a part of me that really liked the adrenaline rush of getting paged in on a legitimate security issue and having to run the call and pull the right people in to get the situation handled. It's a great test of how well you know the environment and where all the pertinent information lives.
4) Know the team size and oncall frequencyakg_67's estimate was spot on. Anything shorter than a month is crazy and you never quite feel like you normalize. Since it's based on team size, know what the optimal size of the team is and that there's funding for it? My team imploded and at the end there were only a few of us on the oncall rotation. Bear in mind that oncall duty doesn't go away because you no longer have the staff to make it manageable.
5) Vacations and sick time are now more complicated
Who has to be oncall during Christmas/4th of July/etc? What used to be some loose coordination with your manager is now a give/take discussion with your team about who covered the last holiday and who's turn it is. It's all completely fair and reasonable and if you have a good team dynamic you can make it work, but it's definitely more complicated than telling Aunt Edna that of course you'll be home for Christmas.
6) Get paid for it
Whether in flexing the hours for the time spend working a page off hours or by getting paid directly for off hours work. No reason to kill yourself for no additional compensation (and there will be those hellish pages or that automated alarm that goes off hourly starting at 3am).
7) Put the operational burden for supporting a thing in the hands of the people who have the ability to fix it
There should be a cycle of:Get pagedRoot causeFixPost mortemDeploy fix so that thing never happens again
If you don't have ownership over the thing that's paging you, you're at risk of getting paged all night every night for something you have to go convince other people to take time out of their schedules to fix to solve a problem that they don't feel. Not a great situation.
One thing I would say is that while the (my) natural reaction when I get paged (sms) is to jump right up and get it done... but sometimes depending on what you are supporting and as long as you use discretion you need to know when they can wait 15,30,45 mins before you get back to them. This small leeway will help keep you sane.
Technically speaking, no private startup can legally take investment from someone who does not meet the SEC's definition of an "accredited investor." The Jobs Act was supposed to change this, but that part of it hasn't come into effect yet sadly.
Nothing personal, but $25,000 doesn't make someone even a prosumer investor. That is the kind of money a company raises in an FFF round. As a stranger, you're neither friends nor family.
It doesn't make sense for a company with traction to take your money. It's a week of operations, maybe. In exchange they get someone without diversification and without experience writing off five figure investments. And that person gets legal standing beyond anyone can sue anyone normalcy.
[accredited investor]: http://en.wikipedia.org/wiki/Accredited_investor#United_Stat...
I don't need money, but I'd still like to buy you a cup of coffee if you're free before Wednesday. Phone number/twitter is the same as my HN handle.
Why not be a technical co-founder in a startup that you truly believe in. Then use the $25k to support yourself and get the startup to angel stage quickly.
25K is barely a yearly salary, don't throw it away by investing it.
I've been working on a Bitcoin related web-based/mobile software for the past few months and have a working MVP (Node.js, PostgreSQL, Angular stack although I'm flexible about using other technologies in the future - Go and React come to mind). I haven't publicly launched it yet (no traction :/) but I'm fairly certain there is a market for it and there are a few obvious paths to monetisation. The idea is novel, it's a white market (no direct competition at the moment) and the barrier to entry is reasonably high (mostly due to technical complexity and potential network effect).
I'm not sure if in its current incarnation the idea could scale to become more than a "lifestyle" business but I have some ideas. I've been thinking about the possibility of getting a co-founder and funding lately. One problem I'm facing right now is that on one hand, I want to give my potential co-founder a large chunk of equity (30-50%) so that (s)he feels motivated but on the other hand, I'd feel a bit uncomfortable about just "giving away" a few months worth of labor and expenses. Having a co-founder who is willing to throw in a small investment would solve that problem.
If you think you might be interested, shoot me an email at firstname.lastname@example.org
That's my biggest pain point, that I have to work to pay the mortgage instead of pursuing my passions and living my life. I'm lucky, my mortgage should be paid off by the time I'm around 35, but I don't want to lose the next ten years to working...I've already been working for ten years, I want the next ten years to be a combination of passion, hard-work, and chasing MY dreams.
When it comes time to purchase, every once in a while the same person that downloaded comes to our online purchase page and we're able to attribute the sale back to the channel/ad/blog it came from.
Most of the time though, someone else (the boss, a purchasing person, etc) on a different PC comes to our online order page and pays. From Analytics point of view they came from nowhere. Or worse, they fax/email a purchase order.
I would love a way to accurately track the source of our sales without introducing painful process (requiring some sort of download ID for example) to the purchase process.
Have an idea -> google for its existence
If idea is novel -> Google to answer questions about implementation;Else -> come up with new spin on idea or stop
Confirm findings or test idea -> have a new idea or new questions
I also have ADHD & can sometimes (ok...often) hyperfocus when I catch this cycle. I can lose hours upon hours in it. But that's not the main problem...
There are numerous ways to enter this cycle (ie. Triggers for any of the habits) & they occur so frequently that they disrupt the development of new habits. The standard triggers are having/encountering a new idea, a question without an answer, or an answer that needs confirming. I can also jump into it accidentally through procrastination means (eg. reading HN) or just as a result of everyday work (eg. searching for something on stack overflow).
I'm a programmer without a support system to enable me to disrupt these habits without unplugging for months, which I can't afford to do.
There was one a few months ago but it has since been abandoned http://electrum-doge.com/, yet there is still large demand for it. One exists for bitcoin that is working though.
It's fast on startup, non-Java and a headers-only wallet with a deterministic backup (1-time phrase based.) I read that the Core wallet might get a deterministic backup in the future.
Such a wallet would be great for newbies. ED also has plugin potential unlike the core wallet.
If you get it going, you could charge for its usage (eg a fee to connect with the servers,) and it may become popular on mobile devices if you could do a version for it (ie small footprint.) You could also do versions for other coins.
Full blockchain wallets are gradually becoming cumbersome as the blockchain size grows (that might be the true pain point.)
A software-defined time machine would probably be helpful :) But really, software to spot patterns and correlations I wouldn't otherwise notice (based on life "microevents" of all kinds, food intake, feelings, interactions with others, environment factors...) would probably help a lot, literally life changing perhaps. A good AI to talk to as though it were just a close friend would make a perfect user interface for such a thing.
Domain specific AI to talk to would help on its own though, long term isolation itself is quite damaging.
The local market sucks so I'm unable to escape from my agency job. I feel trapped making disposable marketing websites that will disappear in a month or two. I have applied to remote jobs but most don't want someone that is not from the US.
I have no idea what to do. I feel like my current job is killing my drive for web development even though I love it.
Sorry for venting here.
It's presold to 129 customers as a subscription before it's even done.
Are there already services out there for this?
Since becoming unemployed, I've started working out more by running around 10 miles a week, giving private Brazilian jiu-jitsu lessons, and even have had the opportunity to assist instruct defensive tactics with the local Police Academy. I'm also eating better, saving a ton of money on gas and on not eating out (I had a literal six charges on my debit card for January, including gas!), and just feel 1000x better.
Now I'm just looking for the next opportunity, sadly it looks like I have no where to go in the technology sector in my area (SW Virginia) and may be moving into a Correctional Officer position with the Regional Jail because plainly, I need a paycheck.
It's scary and chances are I won't make it - but I'm so glad I've at least made a start. At the very least it'll be a nice break for 6-12 months, with some good experience too.
If you're interested in what I'm making, I'm building a simple, affordable web analytics service. There are loads of fantastic tools in this space (Heap is a great example) but they're 1. frankly very expensive (I'm targeting small companies/design studios) and 2. often more complicated than what most people need. Google Analytics has an awful lot of features (and has the advantage of being free) but is really quite complicated, especially for people who aren't as technical.
I should be launching in under a month - please feel free to sign up to be notified if you're interested: http://pleasant.io/
Since I have a very fluid schedule, I designed the new habits as small "chunks of time" around my only daily constants: breackfast, lunch and dinner. Rather than sticking to "I'm going to exercise at 5:00pm" (who knows, I may be busy then), I prefer "I'm going to practice for 30 min. before breackfast".
It's working great; I have a slick kanban workflow on Trello going on, and a (tiny, irrelevant, but useful for this purpose) SaaS app in production.
App #2 is under way ahead of schedule since #1 reached MVP with a full week to spare of January.
It's obviously early days in the project, but I hope to make this my year of sincere effort, and personal growth.
The leap from making money to making absolutely nothing after having just gotten married in October probably looks like the workings of someone who has gone completely bonkers. Even though it's a terrible time for me financially, I feel like it's the best time for my business to take root and thrive. I owe a lot of how I think about this transition to the hacker news community as a whole, since there is a direct correlation between the time I started reading hacker news, and the time I started dreaming of owning my own successful company.
I don't have a landing page set up yet (man there's so much work to be done!), but if you're interested in knowing when Pleenq goes live, send me an email at email@example.com and I'll add you to the first round of invites!
- Spoke at a conference for the first time (React.js Conf) 
- Released my first serious open-source project (an isomorphic React app server) 
- The project I've been building was demoed to some executives and put our team in a really good spot.
Other cool stuff:
- Started buying furniture and accessories to make my room feel like home. I've always been hesitant to own large items because I've moved pretty frequently since I finished high school. Buying a handmade hardwood bed is a big deal for me.
* I've managed to read five books in the first ten days of January! My goal is to read at least one book a month in 2015.
* I've managed to lower my cigarette addiction. Now I am fully able to control myself. If I smoke more cigarettes in a day than I think I should, I can pause a couple of days without smoking a single cigarette without any problems. I feel great managing to control just how much I smoke considering that I don't have the desire needed to quit smoking completely.
* I've found my passion once again. Not a day has passed without me learning something new. I'm actually trying to build my habit: http://r3bl.github.io/en/learn-something-every-day/
* I've completely open sourced everything I do on my GitHub. My notes, my portfolio, my journal, my blog... Everything is up on GitHub and I'm currently in a 14 days streak. I will try to continue at least to 50.
* I've managed to write an article worthy of being published on Opensource.com. It is going to be published by the end of February.
Of course I'm briefly blogging about it as a journal too.
Initial discussion: https://news.ycombinator.com/item?id=8908275
And yes, I did manage to ship in January!https://news.ycombinator.com/item?id=8973807
I am planning Feb's challenge later today...
(PyParallel: native CPython running on all cores without being impeded by the GIL. https://speakerdeck.com/trent/pyparallel-how-we-removed-the-...)
P.S. Hit me up if you're in Seoul in July-October!
2. Started working on Larameet UK (https://james-brooks.uk/larameet-uk/) which will be a mini-conference/meetup for Laravel and PHP developers alike.
3. Moved back in with my parents so that more of my savings can go towards a house.
4. I reached sixteen weeks of not drinking energy drinks; Monster, Redbull, Lucozade etc and reduced my daily coffee intake to two cups max. I'd rather drink tea and water now. I don't smoke nor do I have a particularly addictive personality, but stopping myself drinking these energy drinks has been really hard and continues to be when I'm near them.
5. Finally (after five years) setup a deployment system for our consumer websites at work. This makes a massive difference and is a step in the direction I want to be doing.
Gave W3Counter (https://www.w3counter.com) a bit of a facelift, and a new set of plans & pricing. Offering annual plans has increased customer LTV a lot.
Started testing Amazon Aurora for RDS. I'm considering replacing several bare metal servers with RDS once that service is out of "preview". The feature set is just bonkers for how easy it is to use. The price is just bonkers compared to RDS for MySQL/Postgres -- you get multi-AZ replication for free. Can't wait.
Did my taxes. Waiting on 1099s to come in before I file anything just to make sure everything lines up with my own books.
I had some experience with Angular for making internal dashboards and there I believe it shines, but for regular websites it makes some normally trivial things unnecessary complex - think SEO, back button, rss etc.
I plan to write a detailed blogpost about it but until then you can ping me if you want to know more about my experiences. Happy to chat.
Also started doing a nice trick - get a cool glass bottle, fill it up with water in the morning + some lemons slices and place it on your work desk. Makes hydration so much easier.
Most people think this problem has already been solved by being able to render templates on the server, but the problem is much harder than that. For example, I learned on HN yesterday that most server-rendered Flux apps can only handle one request a time, due to the reliance on singletons. You really need an application-wide DI system like Angular/Ember to get this working with multiple requests in parallel.
I've been trying to meditate for exactly five minutes a day. I'm not sure it's helping but I'm pushing on.
Almost landed my first Fortune 500 client for my one man startup, jQuizzy.
So far, it's heen s kind year.
Botched the audio implementation and had to start over from scratch with the archived code, but that it worked at all (albeit badly) is still better than I would have expected (and on the bright side, I now know how to bootstrap an SDL project with batch files which is so much easier than doing it through Visual Studio's GUI.)
Apart from that, nothing of consequence.
I've also started training for alpinism. 1 hour of hill walking with a 30-lb pack twice a week, plus core/body strength workout, and a 6-10 hour hike every weekend. The gas mileage driving to the mountains is killing me.
* With my spanish knowledge I started to give some courses to help people "hablar espaol". Funny experience.
* I finally decided of which language I'll learn in 2015: Chinese. I though Japanese I'll be cool as well, but I heard Chinese seems easier for beginners... huehue
* I'm actually keeping learning Ruby On Rails with a really intense learning flow. Which helps me acquire some sort of "coding discipline".
* No more cigarettes. Really proud, really.
PS: If you found some grammar errors, I should apologize. Unfortunately, my native language isn't english.
I made significant progress on my sideproject (implemented native mac, linux, and windows clients in addition to the backend!). Shameless plug: It's a filesystem-based time tracker (think dropbox filesystem monitoring + Machine Learning to automatically classify projects = no-hassle, fully automated time tracking) http://moonlighter.io
Personally, we paid off the balances on my wife's car and student loans. Now to continue tackling my own student loans. (Can't wait to only have the mortgage payment...)
* Hit 60K pageviews on http://www.developingandstuff.com for the second month in a row; started splitting posts by content into several thematic blogs.
* Restarted playing the bass, seriously considering getting Rocksmith after trying it out at a friend's house.
* Got my first sale on fiverr: https://www.fiverr.com/mparramon/
You draw on Android (multiple people can co-draw in real time) and also can view docs online (also with realtime updates)
Here's a sample drawing / notehttp://write-live.com/d/dba21681-8d3f-4fbe-8b4b-e5c1983df934
Also, gathered a lot of attention for the ANSI & ASCII art communities (and at least 2 new artists!) with my rewrite (and promotion) of http://artpacks.org.
FYI: A new pack full of ANSI art from Blocktronics comes out today, around 2pm eastern. You'll be able to see it at http://artpacks.org/2015
On January I got the video driver (composite video, PAL; rendering from external SRAM) and the keyboard driver (PS2).
Reading and learning about PAL and PS2 has been very interesting, and also I had to learn a EDA software (KiCad) to keep the schematics safe because the Arduino board has now more cables that I can safely track ;)
Besides I had to understand lots of details about the AVR, mainly how SPI and the USART interfaces work.
Wrote up an article about getting F# adopted in the work place. It got ~1k views https://medium.com/@the_ajohnston/how-to-get-pragmatists-to-...
Wrote up a very domain specific article on scheduling. It got 8 views https://medium.com/@the_ajohnston/dont-use-the-word-reschedu...
January's project was http://finishonethingtoday.com, it managed to hit the top of HN for a few hours and got a lot of attention and continues to bring in visitors and has opened up a few new areas for potential projects in the future :)
Fun tech too.. using chess.js (https://github.com/jhlywa/chess.js/blob/master/README.md), chessboard.js (chessboardjs.com) and Firebase.com at the moment.
Also doing a machine learning project at a nice uni. It's probably the reason for my recovery. It's a way better environment than staying at home getting distracted. I think I now get the concept of co working spaces.
I've been playing both flatpicking guitar and mandolin respectively for 14 and 4 years, but have been in love with the sax for more than 20 years.
At almost 29 years old I decided it was time to take the plunge and learn how to play the thing.
It's going to be a good excuse to finally learn how to actually read music in the process.
I feel motivated like I rarely felt before.
Started reading every night before bed again - trying to read two books / month in 2015, despite a very busy schedule.
Also made a decision on what to build for a new SaaS project.
Decided to build http://expertinamonth.com to teach people to code better.
I will be launching the first set of courses in a month or so. I am looking for course suggestions, so let me know what interests you
Other small wins.-Started to read more again (leisure).-Played with stuff I've had on my list (jasminJS and phantomJS) - They are awesome!
In the real world, got a squirrel out of my attic. :-) Equally challenging!
* Finalized my tax return for 2014 (best year ever for me)
* Tinkered with isomorphic React rendering, and got a working example that loads data asynchronously
Turned The Love Game App into a physical product and produced a crowdfunding project which is live as of yesterday: http://PlayTheLoveGame.com/crowdfund
Sold our first 10 "Get Your Story Straight" packages to VIP customers for $500 each to help them maximize press and onboard them to the PRMatch Command Center & Press Room (http://prmatch.com).
Hosted my first virtual mastermind for publicity, called Publicity As a Path : Foudations of Transformational Mass Communication, with about 80 people attending.
Built The MemeScope, after waking up with a vision that there should exist an online kalidescope that uses recent news images as source material. Http://AnthonyDavidAdams.com/memescope
Have been doing yoga regularly, eating well, playing ultimate frisbee regularly.
Began conversations with Cher's former multi-platinum producer to collaborate on my first album of original music. (He and I cowrote a song a few years ago and performed with John Legend at a charity event.) also wrote the bulk of about 3 new songs.
Launched a publicity tour for my moms new book on leadership that debuted in every Barnes & Nobles. ( Http://DrJanetRose.com/media ) which led to her booking her first paid speaking at around $6k (speaker fee + bulk book buy) I built her brand over the last couple years and have been coaching her, so this feels amazing - she will retire as a school administrator this year and this work is her passion for retirement.
Took on a couple new davinci / polymath coaching clients (life, love, creativity, strategy, marketing, pr, etc) and stoked to watch them flourish this year.
Started successful negotiations with a new manufacturer after my factory for my patented CreditCovers skins for Credit Cards decided to breach our 30 day termination clause and just turn off drop shipping.
Built / archetected a marketing program, web site, toll free hotline and produced a book on TreeCare for SC Homeowners -- as a gift for my childhood best friends business.
After applying strategies above mention best friend used to get 6 figure credit lines at 18 (and then like any good 18yr old, defaulted) rebuilt my credit after some trouble in my twenties from starting projects on credit cards -- got issued a Venture Card at the "Excellent Credit" level and another card, with credit lines 10x what I had previously. Stoked to learn from his mistakes and leverage some really great, easy, legal strategies and feels amazing to have this cushion / tool available again.
Upgraded my relational contexts to where I am 95% less attracted to people who aren't available for the kind of intimacy I want -- this has probably been the "one wierd trick" that has opened up so much other flow and productivity. Watching how I would often optimize for relationships where I felt neglected or abused or unmet, and now spotting that pattern, extracting the gift the pain of those relationships brought me, and transcending it. I've developed a process I am now coaching people on that allows folks to use the relational space and conflicts hthat arise therein to literally reprogram their midbrain, gain insight and unlock tons of creative energy and potential.
Caught a great Phish cover band last night in Charleston, Sc - Runaway Gin
Great question, I feel like I got some shit done this month! A lot actually!
Strong points: Performance is really exceptional. No problems running visual studio and SQL server.Battery life is great as well. I get a days worth of usage out of it. Bought it refurbished from Apple so I saved some money.
Weak points:Some annoyances with slow wake up and connecting to wifi after wake. If that is the trade off for getting incredible battery life then it is OK.
I've had it for almost 7 years. It doesn't choke on anything since I bumped the RAM from 4 to 12G - I was having issues with running virtual machines.
Operating System wise it's got a 50 meg FreeDos partition at the front of the bootloader for when I screw things up. There's Windows XP Professional X64 edition and CentOS 6 on one of the 250G, the other 250G has Ubuntu Studio 14.04. The 500G has Windows 8 that was upgraded over a Windows 7 installation. By default Grub2 boots to Ubuntu Studio (without the low-latency kernel). By default the system will boot to FreeDos if I've hosed Grub.
I wound up with two different size monitors because there was only one 22" in stock and on sale when the old 24" died. It turns out that the 20" rocks because of it's lower DPI/larger pixels. I can kick a window to it and read it from further away - i.e. leaning back in my chair with the keyboard on my lap (the MS NE4000 is designed to sit in your lap, ergonomically no less).
Away from the desk, I use my Android phablet - an LG Optimus Pro. Now that I've got a Logitech K410 keyboard for it's even more useful. There's also an old Vostro in the house and my ancient Toshiba Satellite 1805-S203 with Wary Puppy (the video connector to the display has become dodgy, unfortunately).
Printers are my current focus. The Brother MFC-5405 crapped out on Tuesday. The refurbished Citizen GSX-145 from ebay arrived yesterday ($5 buy it now plus $20 shipping). Waiting on the right cable from MonoPrice - I stupidly ordered the IEEE 1284 the first time because it sounded better and I had overwritten the Centronics and Serial cable brain cells. I put the HP LaserJet 2605DN up for sale on Craigslist. The Epson Workforce 1100 will go down to the family room. The Satellite may wind up a wireless print server.  I'll probably get a bespoke scanner at some point. But I will soon be tractor fed impact ribbon reliable for when I want to print.
If you've read this far, there's probably something wrong with you. But obviously not as wrong as what's wrong with me.
 I stuck a Broadcom wireless G daughter card out of an HP laptop with a cracked screen in it.
Ive been getting into gamedev in my spare time recently and have been reading a lot of devlogs to learn a bit more about the process solo gamedevs in particular go through. Out of curiosity how have you found the past few years to be, working on this full-time while trying to provide a decent living for yourself?
I would recommend having them think about applying to the iOS jobs to being similar to trying to get a job as a game developer. They will normally not give you a call and send your resume to the shredder if you do not have some quality work to show for. When they present their app it needs to be something of substance that the potential employer or even an HR person can enjoy to help them get their foot in the door. It does not have to be extremely complex but can be simple, fast and to the point.
Apps they can start off with are better quality feed readers then what is currently available in the App store for a specific site. If they are not at the point where they are comfortable doing full blown apps and publishing them, collaborating with someone on an app on GitHub can be a good alternative. This will help display their code quality which the person normally giving the green light to higher will be a developer.
If a developer sees someones good code and thinks that mentoring that person will be fun and a great challenge to spread the knowledge the interviewee can be hired before they even make it into the interview (interview being left to make sure the personality is good to go, there is enthusiasm and drive to learn new things and at times so the manager can get a feel for the guy.)
As always, sometimes when we are starting out all we needs is that small chance to grow into very competent developers with others to mentor us and help guide us in the right direction (learn from their mistakes so we don't have to make them all on or own or learn everything the hardway) just remember it just takes time, normally it is is hardest right before you get that chance.
With that being said, I am quite willing to throw my own personal time and energy into coming up with a long term solution for this family. If you are interested, my contact information is in my profile. Feel free to reach out.
Of those, VHS or Floppy are probably the most likely to be accessible today. And it would be painful. I would suggest multiple backups each in multiple formats. I'd look at .ISO formats in both several hard copy and cloud archives. And more native formats in the cloud.
The key is to have a team that is willing and capable of stewarding the material as technology changes and services break down.
My best wishes for all affected.
So no healthcare, no company provided machine on your desk, no paid vacation or sick leave, no retirement contribution, no invite to the xmas party, and no stock options or equity.
Negotiate your contract with that in mind, and charge accordingly. When and if you decide to do the "to hire" part of the arrangement, negotiate that bit knowing that equity and free cake at Stan's birthday party are now back on the table. (Favor the latter, as it's likely worth more).
Do you have some further concern about making this happen?
I found this book helpful
function learn x if x.prerequisties.know() then study x else learn x.prerequisites
That's not to say that building up iteratively from foundations is bad. But if it's not directed from the top level, then it may not lead there.
2) Make sure you understand how the math relates to the actual real world and is a means to model actual reality.
I know you did not ask for resources, but really good ones are hard to find. So I will note that a good source for good math articles (as well as good math answers) on HN is Colin Wright: https://news.ycombinator.com/submitted?id=ColinWright
I started in tech support in '98. I worked my way from a trainee associate in Sophos's UK support team to managing a department of 30 in 5 years. I left Sophos in '06 to start my own business.
I am in a similar position to you in some respects. I started my own locally-focussed business as the tech guy. I placed an ad in the local parish newsletter for 25GBP (~40USD) for the year. That ad has paid for itself 400+ times over since then.
B2C support is tough. My demographic is adults, typically 40+. People are sometimes reticent to ask for help, especially with cheap laptops. Be approachable. Be a nice guy. Be professional. Be honest.
You'll learn about your area pretty quickly. I started out with an external hard drive and a screwdriver set. It's 90% laptops and tablets, and the repair side of my business is slow to catch on. The low purchase cost of laptops and tablets makes people less ready to commit to fixing things, instead choosing brand new. Sad, really. Apple device users tend to be more keen to get things fixed up.
Poke around on /r/computertechs and start thinking about a software toolkit. Get a basic website and sign up with iFixit Pro. Familiarise yourself with their store; they do good parts at fair prices. My website isn't anything special (and isn't finished, either), but gives you an idea for what works around where I live.
So, i believed tech support is still an important role. :)
I find younger people I interact with to be more comfortable with technology, but on the whole more disinterested and frustrated with troubleshooting. Getting paid by them might be another story, but you'll see plenty of < 25 year olds waiting for hours at the Apple store to get their phone restored.
Then they aren't your target market, but perhaps older people are.
As the world gets more technologically advanced, the result is that fewer people know what to do when their devices don't work. If anything, the number of people who need your services might be increasing, not going away.
With less than $50 of tools you can be in business.
Insecure men also struggle with their manliness. This is usually a taboo topic, but you need to address it and be sincere about it: do you feel emasculated? "Without saying it goes that I still don't have GF or wife. I am 29 and getting near 30 is a bit scary." There are more people than you realize in your same situation; worse, there are people who married early and are now stuck in a loveless, bleak marriage. one of my mentors I respect him so much! found the love of his life in his late 40s, after an awful, awful marriage.
You're a free, young man in his quest for manhood and respect. Just like everyone else. :)
Lastly, let me link you to a post where I addressed my insecurities: https://news.ycombinator.com/item?id=8745651
If you need an e-mail pal, reply to this post and I'll give you my contact information. :)
If you are throwing a party and invite 100 guests, only 10 will show up. 9 out of 10 will flake out. This is normal and that's how people work.
People don't initiate conversations. It's very rare to meet somebody who will initiate conversation, and keep it going. If you want to have good time, that's on you (to keep finding topics and jumping from theme to theme, have a lively back-and-forth going). It's a skill you can learn and is incredibly easy when you get in the groove.
People don't jump on it, when you invite them to something. For 10 attempts to do something, only 1 will succeed. The key is to keep going and simply have 100s of ideas and keep inviting people. If you are not inviting, nobody is and NOTHING ever will happen. People just keep waiting around, standing around and are incredibly passive in general.
And it's not like everybody is going to parties and you alone are not invited. Nope. It's a desert. In fact, if you yourself don't think of some activity, nothing is happening ever. And most people seem OK with this kind of quiet existence.
The only thing wrong with you is that you have higher expectations (and desires) than the baseline. The solution is - go and make what you want happen. The way to do it: keep having ideas and inviting people. 9 times out of 10 they will decline. That's completely OK, just keep having ideas. 9 out of 10 times when you actually go out and do something, it will not be very exciting. That's the reality and it's completely fine. But then during 1 out of 10 times magic happens.
You really should just try asking a close friend, family member, co-worker, classmate, or anyone you spend (or used to spend) a lot of time with (in a friendly capacity or otherwise). That said, the fact that you're asking HN rather than a close friend, family member, etc. suggests that doesn't work for you, for whatever reason.
So try this: go to a random meetup, chat with a stranger for 15-30 minutes, and then ask them if there's anything about you that seems off-putting. If you feel uncomfortable asking that kind of question or if you're concerned that you won't get an honest response, tell them you're gathering data for a study or something.
And if that doesn't work, you can always schedule an appointment with a professional therapist.
Most social groupings are formed out of blood or forced closeness - small towns, religious groups, schools, the workplace, housemates, etc. These are people you spend a large percentage of your time with, and they tend to be non-transient factors in your life - i.e. continued social interaction with them is likely over a non-trivial timespan. You can count on these people being around in the future, so the investment of effort in cultivating relationships with them has a high expected payoff.
Compare this with the modern, post-collegiate experience for most 20-somethings. Seeking gainful employment often means leaving behind the familiar contexts one was born and raised in, abandoning familiar social nets, to move to more economically dynamic areas, with larger and more diverse populations. Turnover in employers and fellow employees is vastly higher than it was a generation ago. Tied with this, long-term home ownership is less of a realistic proposition, so the community of locality that comes with living with and getting to know one's neighbors is diminished. Other people are more transient and disposable in this world, and the general uncertainty makes it more difficult to focus the effort on building relationships, particularly when you are trying so hard just to get by, day to day, week to week.
I don't really have a solution, but this seems to me to be the problem.
1. Maybe nothing is wrong with you and the people that aren't reciprocating aren't the right people for you. In this case, consider ways to find new people, activities, etc., or try to be more comfortable with the fact that you're special and it may take some time to find the right people (but do as much as you can to increase your odds such as hobbies you love, etc.).
2. Maybe something is wrong with you in the sense that your brain is creating emotional pain in the same way that your body alerts you to physical pain. In this case, first be happy that your brain is trying to help you (even if the emotional pain is... well, painful). Next, consider exploring your emotional pains through philosophy, psychotherapy, positive psychology, exploring your childhood and close relationships, etc.
Each of these hypotheses branches out to many other hypotheses, most of which can be "tested." If one of them isn't yielding a good theory, move on to the next, and you may ultimately find something. Keep trying!
So, what you need is self-sufficiency. Once you get more comfortable being in your own company and doing stuff on your own then people will get more interested in you. Pick up some intellectual interest or activity outside of your work and preferably not related to it. Consider getting a dog - seriously It's surprisingly emotionally rewarding plus you get automatic entry to this whole secret society of dog owners and an automatic icebreaker/topic of positive small talk. I wasn't into dogs at all until I rescued one, but it turned out to be a big positive and well worth the required lifestyle adjustments. Also, women will size a guy up by how he relates to his dog. If your dog is chill and happy, then people will come over to tell you how cute it is, and this will reflect onto you.
People make friends with friendly people. Friendly people enjoy the act "giving" friendship.
They give you fresh baked cookies just to you to see you smile - not because they expect you to do something in return.
They ask about how you are feeling ("How is your back these days?") because they actually care - not because they want your help moving.
Making friends becomes a by-product of being generous with your friendship.
Consider NLP, consider getting involved in things that you find uncomfortable (e.g. amateur dramatics). Join meetup.com and locate groups in your area doing stuff and pop along. Talking to people is hard.
Smarten yourself up. Make yourself look great ALWAYS. Change the way you get to work. Consider cycling/walking. Exercise. Run a half marathon. Follow a passion. Get into local campaigning. Be involved in society. Join a debating society. Avoid MMORPGs as a social outlet ;)
Love yourself (but not in an arrogant way).
AND when you are ready, do something crazy.
You're almost 30. It's time you circumvented the world by train and boat. Consider backpacking around India. Go climb a mountain. Tour across America on a bicycle.
You're single. You have no dependents. You can go anywhere and be anyone. Telecommute from Vietnam.
I would say your statement about going to clubs indicates a way of thinking about getting 'hooked up' that probably does not suit you.
Also hanging out with work colleagues is not good. Going for a drink is fine. People have their own social lives and doing drunk stuff in front of work colleagues can be a very bad thing. People connect with people at work because of the interests they have outside of work, not because they share the same workplace.
Maybe suggest moving into a house with a group of people.
I would also say that from the way you state people don't talk to you is that you have a personality trait some people find uncomfortable.
Also, make sure you have the basics all covered. I'm not saying any of these apply to you specifically as obviously I don't know, but the basics would include proper hygiene, good breath/dental care, dress in neat, clean clothes, etc.
Finally, you also might want to try reading some books on the subject of interpersonal skills. There are a lot of quick practical tips in the areas of body language and ways to communicate that make other people feel good about themselves when they are around you.
My personal experience with friendships/relationships is that it is a chicken and egg problem. It's a lot lot lot easier to make new friends when you already have many (same goes with romantic/sexual relationships). It probably has to do with social proof dynamics and the fact that you might be unintentionally signalling insecurity through body language and appear to be desperate. It's possible that a lot of the people you talk to think something like "there must be a reason this 29 year old guy doesn't appear to have any friends".
One drastic solution would be to move to a new city or country which would make it more socially acceptable for you to openly seek out new friends without appearing to be desperate. Another option would be to join a local sports team or other group activity where socialising isn't the central goal (poker, working out, hackatons, hiking, etc.).
Finally, HN is probably the wrong crowd to ask for this kind of advice. http://forum.bodybuilding.com/, http://boards.askmen.com/ and other similar "lifestyle" communities would probably yield more interesting results as a lot of the people on those forums are there specifically because they have gone through similar situations.
I felt rather similarly in my early and mid twenties. I didn't click with people, and it always felt like too much effort to socialize. Then I moved to the Bay Area and my life changed over the course of two months. I finally met people with interests and goals I could relate to.
For what it's worth, if I were doing it again now, I'd move to a great city and exploit things like Meetup.com, get out, and take up every class and activity that so much as caught my eye.
Remember: to be interesting, you have to be interested.
Perhaps appearance issues - from being overweight to having sweat stains to not smelling nice to having too long fingernails. Perhaps interaction issues - not making any eye contact, making too much of it, taking down to people, sucking up to them, etc. Perhaps personality issues - odd sense of humor, lack of overall confidence, over-confidence, pushy / boring / quirky personality, etc. It can be anything or a combination of thereof :-|
# That all said, I'd say the first impression you make and the overall confidence are the two most important things to pay attention to if you are looking to change things.
- If it's something casual, don't be too pushy. Like we learned in D.A.R.E, leave the door open. So if I ask someone if they'd like to come out to get drinks and they're not sure, I just say "No problem, text me if you want to come, we'll be there." For more formal events that require reservations, get a commitment well in advance.
- I find that if I'm doing something that the person I'm trying to invite hasn't done before they're more interested in coming. I do my best to make it easy on everyone so I lay out an exact itinerary, offer to do the group purchasing, and make sure everyone has a way to get to the event.
- I find that posting some post-event photos on Facebook help a lot as people see the fun they're missing out on.
- Don't be afraid to have fun by yourself. I enjoy rambling around new places by myself and the more I put myself in new situations, new places, the more often I find myself meeting new people.
That said, it's a good question to ask. I think most people who have trouble socially don't ask, and end up unhappy without realising why. I'm going to try to answer the related question: "how do I find out what is wrong with me?"
There are two people I think you should talk to:
Firstly, someone who would have been affected by your problem (if there really is one). You just need to ask them nicely and in a way that doesn't make it seem personal. If someone I knew said "Hey, I'm trying to improve myself. Could you tell me honestly if there is anything I'm doing that makes people uncomfortable?" I would do my best to help them.
Secondly, a therapist. They can listen to how you feel about social situations and help you figure out how to deal with it. Keep in mind that social anxiety is one of the most commonly reported mental health issues. There may be nothing wrong with you in social situations except the way you think about them. I can't say for sure because I'm not a therapist, but this kind of problem is exactly what they do.
Good luck and I hope you find your answers.
Bottom line: Be someone YOU respect and like. The rest will take care of itself.
If you don't like yourself, nobody else will.
Be genuinely interested in other people and they will like you. Respect their opinions even if you disagree.
More on my opinion and less on this book (which as I said I have only skimmed for now so can't really judge), I believe in the LAMPS theory: girls tend to be interested in Looks, Athleticism, Money, Power, and Status. I think you can gain a lot of the last 3 just by working hard on improving your own life. That book says you can be yourself and that girls will like you even more for that, but maybe that's just signaling Power/Status, or maybe LAMPS is just not a good theory. Ultimately though, in today's society you really just need to look good/healthy, have a fulfilling well paid occupation, and give the ladies (or other people) exactly what THEY want; you can't be selfish. It's not about YOU becoming less lonely, it's about being interesting to other people.
Nobody should be hurt. It's my life, that's what it is, the day has only that many hours, things happen, and things will change one day. Right now, I don't even have time for myself.
Don't go out and look for friendsnever do this.
The problem is that people will smell it from the first moment you are around them. They will know when they see you looking at them, how you approach them and how you talk and how long you talk with them. You signalit's basically written on your forehead: 'I need friends. I want friends. I am lonely, I am needy and full of despair, please f*ing talk to me.' And this neediness makes you as a person very unattractive. It's not your looks.
I went through a similar stage for a long time but could get out, now I have again tons of friends, a lovely girl-friend and life is good. Let me know if you need more advice.
Then again, some people are just incapable of socializing. I know at least one person like that who is older than you, single, and gets looked over for a lot of activities at the community group we both frequent because people feel that he's incapable of holding a conversation.
Yet he's harmless and tries to be social but it just comes out wrong and in all his years he has never learned.
Then on the other hand I'm 30 and I just recently in the last 4-5 years started blossoming. I'm not saying I'm extrovert yet but I've realized a detail about being introvert and that is that we thrive in social situations as long as we can rest after and recuperate. Resting requires silence and alone time, or time with very close friends and spouses.
Also toastmasters, meetups good. PUA types can be helpful but also can be rubbish. I think a lot of social types spend years on the social stuff in school uni etc so geek types can sometimes have some catching up to do.
If you think it may be leaning towards the latter, try to look deep within yourself and understand what it is you need. The next step would be to meet this need by yourself. Trying to use other people seldom works well, in my experience.
On the other hand, if it's the former, does it come across to them that you are genuinely interested? Do you keep eye contact most of the time? Do you pay attention when they are talking, and do you listen to what they are saying without thinking about what you should be saying next? Are you listening more than you are talking?
"You see your report here says that you are an extremely dull person. You see, our experts describe you as an appallingly dull fellow, unimaginative, timid, lacking in initiative, spineless, easily dominated, no sense of humour, tedious company and irrepressibly drab and awful."
"And whereas in most professions these would be considerable drawbacks," in your profession "they are a positive boon." (You work in front of the screen the whole day anyway).
Since many and me wrote that you should NOT go out and look for friends since it makes you needy and people smell the neediness it's is important to note that having a few good friends is the key to happiness. Just one or two is enough. People you can call anytime.
Now I said that you shouldn't actively look out for those but I am saying at the same time that they are the key for happiness. Without friends depression comes quick.
Let's dive into 'friendship', what are friends? Is there an abstract concept for it? Or what is more interesting herehow does friendship evolve? It's quite simple and we start with an anti example: imagine you met a guy some night you went out. He has some similarities like same interests und you guys both recognize that you need friends and decide to meet more often to do stuff together. You go a few times out and then you guys realize that you have nothing to talk anymore. So you decide to do some active stuff, you guys play tennis, it's fun but you guys are still not friends, after the match you head to your places without talking too much. You go out more often, chase girls together. Fun but you still no friends, rather competitors. So why did no friendship evolve here? You guys had the same interest, did many activities together and still feel awkward together and have nothing of significance to tell?
The answer in my experience is that the relationship I describes before is based on a voluntary setup that means that nobody forced you guys to be together. Every time you met you had to act to see each other, no external force brought you together.
A beneficial setup for evolving friendship is a forced community with a hostile participant or just somebody with more power. Friendship easily evolves there where people have a common enemy and the need to form alliances. School is the perfect example with the teacher as the enemy. The older the people get there are less forced communities. You office is also a forced community with managers as 'enemies' but since there is a lot of change and office politics involved friendships there are very prone to fall quickly apart.
The bigger/stronger/tyrannic the enemy is the stronger your friendship will be and once the enemy is away you friendship will slowly fade.
So my suggestion is that you join some group doing things you like - be it art, music sport or anything else that you like and will introduce you to different people (suggestion: not some technical group).
My personal change came when I joined a sports group (triathlon in my case). I was never a good athlete but I did get a change to meet a lot of new people. Indirectly I have found my wife through that group.
There are lots of books on self-esteem and social improvement. I suggest you read a few.
The best way for you to receive an answer that is close to reality is to visit several psychotherapists and talk to professionals qualified to talk about your personal issues while maintaining your privacy. It would be also beneficial to learn more about meditation, self-awareness and psychology in general.