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.
The fact that you are on HN and able to have this kind of insight proves you are capable of hanging with the youngins.
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.
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.
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.
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!
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.
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!
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.
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.
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.
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.
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.
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 email@example.com
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 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.
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: firstname.lastname@example.org
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?
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.
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."
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.
Really, you should ask the people on this new team, not HN.
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 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.
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.
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.
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!
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.
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.
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. 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.
I managed to fix this by getting a new job where I didn't have to manage. ;)
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.
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?
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.
"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. :-)
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.
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.
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.
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.
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.
"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 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.
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.
How can I stop this behaviour? It's like I'm not in control, I just get carried along by the current.
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.
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.
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...
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.
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.
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.
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.
- 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.
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.
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.
Be genuinely interested in other people and they will like you. Respect their opinions even if you disagree.
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.
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.
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.
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.
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.
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.
Excel VBA and legacy business systems and nasty abandoned PHP and shitty Java monoliths are way more common out there than Angular and Node and the like.
"solved many business problems with languages I didn't previously know, such as Excel VBA" sounds like it would make you a fantastic employee for any number of small businesses out there, the trick will be finding them.
I lucked into my first gig via a short-term contract (through a friend) that turned into full-time employment. The job was a mix of Filemaker (which I'd never touched before) and PHP and weird CSV import/export formats (so, basically the most awful combination of technologies in existence), but I solved real problems and was of real value to my employer. Sounds like you could pretty easily do the same, you just need to look for the opportunities.
The stuff that gets talked about on HN seems to be a weird microcosm of cutting edge tech, too much money, and "we have to convince investors we're worth buying so we have to keep up with all the buzzword tech". Meanwhile the other 99% are just tucked away in small businesses solving boring business problems with boring legacy tech and keeping the world turning.
My only advice is to keep applying and work on something while you are still unemployed. You left out whether you've been getting interviews or not, which might be important to see whether it's your resume or interviewing that is the problem.
Experience matters more than pay. Do anything to get a software or IT job, and then eventually hop to something better. Howard Stern (the super rich radio guy) used to make barely anything for a very long time.
You should apply for the less flashy jobs at bigger companies that tend to want people with a solid formal education.
There's probably a thrift shop who will take it to sell and put the money toward charity. It even could be sold yourself on Craigslist and the procedures used to support whatever cause exceeds Goodwill in merit.
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?
Your success is now measured by your team's success and their failure is your failure.
Deflect praise from you to your team. Attract criticism of your team to yourself.
You will have to make decisions your team don't like. Get used to it.
Each team member is different. Listen, communicate and coach.
Let's say I've been working for almost 3 years in which i have developed fully on my own Android, Java Swing, Php, AngularJS, C and managed an apache server with FTP access and virtual domains.
I know half of the people I went Uni with would cry and weep at the prospect of doing my job, but still, there's nobody to say that I'm senior.
Maybe the person applying just doesn'ty know he's Senior, after all there's no Standard.
Maybe he's just unemployed and feeling the dread of poverty.
Maybe he has a shitty job and just wants to flee or get better opportunities of improvement.
Their thinking (and I know some people who've found this) might be that it's easier to get hired as a slightly-overqualified junior developer and promoted to senior within a year than to get hired as an average senior dev.
Most of my experience is C/C++/PHP. Suppose I want to get a job using Python. I'm not senior, because I don't have 5+ years Python experience. I'm not really entry level either.
So how do I switch to using Python?
What happen when demand for my current experience dries up? I'd have to apply for entry level jobs in other tech stacks.
Am I really less employable than a recent grad? Is my experience really worthless? Was this a stupid career choice?
2) Might have personality issues
3) Might have been fired
In my experience, having someone over-qualified is a bad move. However in development, isn't there always "senior"-level work to do?
I'd say it's not worth following up if you're busy, as great people usually know they're great...
Ah, but if you contribute to Wikipedia, someone DEFINITELY will correct your mistakes, AND in a way with rudimentary version control, so you can compare what you wrote to how it looks after the editors swarm in. Find a page on Wikipedia in your language about something that interests you and translate it into English. I personally use this technique to maintain & keep learning my (non-English) foreign languages, and if I can get a response from non-English wikipedia you can DEFINITELY get one from English Wikipedia.
It's true, people are hesitant to make corrections. For one thing, although what you said might not have been completely correct, it was perfectly understandable. Another thing is that they might not know how best to make the correction without hurting your feelings or seeming pedantic. You just can't count on people to correct you.
One useful thing I did lately was to get on WeChat and start chatting with my Chinese friends. Many lines they send to me are goldmines of useful expressions, expressed naturally. Slowly but surely, I'm building up an arsenal of fragments I can use in situations that come up a lot. And I think each little fragment I master tunes my neural network to make learning the next fragment a little bit easier.
You say you can't learn from audio/video courses. I hope that's not true. I would think very carefully about why it's impossible. Maybe there's a way, and if there is, that would very very very useful.
I fyou don't have access to a native speaker, the next best thing is to practice with movies. Audio/video courses are no good because typically you are dealing with isolated sentences or very artificial conversations - you don't care about any of the imaginary people or their situations, so your brain is not doing any work to imagine what things they would want to say. Pick some English-language films you like a lot (because you are going to have to watch them many times) and watch them with subtitles in your own language, then subtitles in English, then without any subtitles. Practice repeating the dialog to yourself, as if you were going to do the work of an actor. You can also practice writing out some of your favorite parts.
Repetition has value, in the right context. The story and characters are easy for your brain to engage with, so they will function as a mental anchor for the more abstract patterns of grammar and correct usage.
Additionally Cocoa was designed with Obj-C in mind. There are current learning pains with Swift on trying to understand how to best bridge Cocoa.
And Swift is a more complicated language than Obj-C. There are a lot more concepts to learn in Swift. (It seems like every other Swift article I come across is something about optionals.) Brent Simmons just posted this which expresses this issue:
And the performance of Swift is not at par with C in most cases. And debug build performance is terrible for anything realtime/multimedia/game centric. This was recently discussed by David Owens II:
As for resources, I recommend Aaron Hillegass's (of Big Nerd Ranch) Cocoa Programming books. He has trained generations of Cocoa programmers well, since the NeXT days.
I registered it in 2005ish before that whole niche in porn took off, some dude offered me $100 3 days later, being young and naive I took it thinking it was a great flip. Year later I watched him sell it for $100,000. I learned my lesson that day.
My biggest domain-fail was letting Naked-Celebs.com expire. I bought it for something like $300 in 2009 and forgot to transfer it to my main portfolio, and somehow let it drop... I still shudder thinking about that sometimes.
It was a huge amount of money but it made sense seeing as the buyer was a business with a 2 letter name.
I agree with supply and demand, and letting market forces dictate pricing etc etc.... but domain squatting is one of my biggest pet peeves out there.
Which left such a big hole in my poor little bank account (I am a college student)But one year later, turns out it was worth it, every penny of it. :)
purchases for employer
party-------.com for 5500
---force.com for 12000
-----lite.com for 11500
7 letters, .com address, six or seven years ago
Solid domain name, and I had an interesting product for it. Didn't materialize the way I hoped, so I shut it down. I've kept the domain though.
I've occasionally run across domains in the $5k range that were quite good, but I still seem to find good enough .com addresses that I've yet to resort to buying one. I'm working on a new product now that is a 5 letter .com address, I bought it straight from a registrar, and it's exactly what I was looking for.
I've probably only owned one that was stand-alone valuable. I bought a domain in 1997 via Network Solutions, and have held on to it since then. It's a six letter .com dictionary term.
c.gg for $50 EUROs
You can add new sections by setting $MANSECT. So I added a new section named with my initials, pj:
Of course you would substitute all the above with your own initials or whatever.
You don't even have to write the files with the usual formatting macros. Most of the time a plain text file works okay. But it's kind of fun to learn enough of that to get by: probably less than a dozen macros for paragraph breaks, underlining, etc.
And then you can put your collection of notes on Github like here:
Here is a file with a few man macros:
I also keep forgetting my password :-(
Make sure it's all done properly, in writing.
Some assurance that you guys will be around in a few years time and that this is a solid model (well aware things like Bench.co would already validate this for you). Trust that you guys actually know what you are doing (I see you are certified accountants but it still feels off for some reason).
Actually, just contrasting what you have with Bench is a good example. If they did Australian bookkeeping I would sign up for them right this second despite the fact they are almost 3x the price of what you are charging.
If I could make an extremely crude attempt at summing up some of the things that stick out to me in the first 60 seconds it would be:
1. This looks like a generic theme from themeforest or something that had little customisation done to it out of filling the blanks. Fonts are all generic, images are all clearly stock photos.2. Who the hell are you guys? Show me some faces, give me some profiles of some of the accountants on your team.
Otherwise, for real I am a genuinely interested potential customer. Would be happy to chat further if you like. mark [at] afterwire.com.au
+ "Bookkeeping Services For Your Business" The headline is short and stands out
+ "Request an invite" Call to action stands out and repeated on top & bottom. However, I'm not sure what this action will accomplish. Will I get access immediately? Will a sales rep contact me?
+ Listing partners and "featured in" makes you feel more important. But is Oracle really your partner somehow? (you mention OpenOffice.org) Also, perhaps add client testimonials?
- Font sizes are all over the place. Headline should only have one font size. The brief summary right under it should be bigger than the standard-sized text in benefits descriptions, etc.
- "Learn more" link is below the fold on my 15" laptop screen, and the page looks quite complete without it. Some people might not get the idea to scroll down depending on your audience.
- Instead of "Submit" and "Send" buttons, use descriptive labels like "Request invite" (bonus points: A/B test a few variations)
- Benefits are impossible to skim. The sections should be titled in a useful way, e.g. "Deep Analytics", "Low, predictable cost" etc.
- I've just noticed you have a dedicated "features" page with more content. And "prices" and some other stuff. But they're buried in the footer in tiny gray text. No one will see them. Also they open in a new tab? Boo... But good that you have the call-to-action on those pages too.
- Front page doesn't really address why I should choose your app over something else. It is a web app... right? I'm not sure because there are no screenshots, not even a teaser. That alone would be a dealbreaker for me personally, and I feel that unless you're selling something for $1000/month and do high-touch sales, you do need to at least show me your product, let alone let me register for it without invites or contacting sales.
- Please, please don't use puzzle (or humanoid) clip art. Even if it's custom-made for you... It's such an overused concept, my bullshit detector is screaming Full alert. This is not a drill every time I see it.
You can improve the overall design of your site by focusing a little on the typography.
For instance, your font stack is currently "Arial, Helvetica, sans-serif". I think a different font, eg. Open Sans, which is available from Google Fonts, may give your site a better appearance.
Also, pay attention to the line-heights and relative sizing between headers and paragraph contents.
These are enormous pain in the arses if you aren't a design-centric person, but are subtle differences between a website that looks polished enough to get the user to give up their e-mail address and not.
I don't have much to say about your site because I'm not 1) a design guy 2) in the market for bookkeeping or 3) Australian :-)