You're the developers' peer, and will have to do a good chunk of work convincing them that the work you think is important, is in fact important. Everyone has gut feelings on what the project should be and where it's going. Your job is to provide hard evidence and tracking of that on behalf of the end user.
Also you're not a full time dev anymore. Don't take dev tasks on unless they're menial and no one else wants to do them. Nothing undercuts trust like doing someone's job for them.
Communication seems to be key. Ensure you understand and that you are understood.
- Communicate, communicate, communicate. Give status updates. Ask for status updates. Get information from customers to your development team. Give updates from your dev. team to your customer.
-Be the voice of the customer. Know if it's more important to be really good or just get the dang thing finished. Let the development team know "we need to cut corners on this one because that's what the customer wants" if that's what needs to happen (of course, don't compromise safety).
-Take care of external roadblocks. Get API info, product specs, pricing, timelines, deadlines, etc... and find a way to effectively give it to the development team.
-Assume your dev team knows best how to build, test, and ship the product, but ask them questions to find out why. Don't be authoritative, but rather put on the attitude of a student. E.g. "I hear you saying we won't be able to ship next week. Why is that? What caused that? Is there anything I could for our next project that would help prevent this from happening?"
-Do project retrospectives.
-Learn the art of minimizing meeting length but maximizing their effectiveness. Communicate, communicate, communicate.
Your time will usually be much more fractured than it was a dev, as you track multiple ongoing projects at various levels of detail. If you try to keep everything in your head, you will most likely start dropping balls, and if there's anyone who shouldn't drop balls, it's a PM.
So, my advice: make lists and track the status of everything you can.
"A large percentage of my time as a PM (project manager) was spent making ordered lists." - Scott Berkun 
Dev productivity killers: * Notifications * Meetings * Emails * Interruptions Great managers block these. Bad managers cause them.
Chances are if getting promoted you are good at it, whatever that is, probably better than most your manages. Find someone that thinks in your same patterns and delegate as much technical issues to his guidance, so you will have no surprise if you need to turn your back at the technical aspects while solving budgeting/timing/serivces issues.
Be prepared to say no to improvements, that's a hard thing to do for programmers turned managers. If you have a chance, get a 10% contingency on tasks so you can gift good devs with time to branch out their ideas.
Be sure to rotate menial tasks to prevent burnout, it's easy to pin them always to the less skilled but that does nobody any favor.
Depending on your org structure it may be impossible to be autonomous on budget/spending/allocation, use that to negotiate timing. "I need x to finish in this timeline or need the timeline shifted by y" works most of the time if you're not happy with a given objective, especially if x is controlled from above.
2. Always remain calm and patient.
3. When people make bad decisions against your strong advice don't feel the need to make their bad decisions a success.
4. Don't own the failure of people who don't understand software development. You'll always be doing the best you can with what you're given.
5. You'll be remembered for your grace and professionalism.
6. Never tell a lie. Never get hand wavy.
7. Never use the word "should". Normative speech has no place in software development. It will embarrass you.
8. Always protect your team from the bullshit that rolls down hill. They'll notice. Then one day when you have to ask them to do something ridiculous they'll know you fought like hell before you had to bring it to them.
9 & 10. This goes without saying but don't write checks (make commitments) you can't cash. Projects will succeed or fail no matter how easy or hard they look at the outset.
You know how to program and do the technical design, but do not do that anymore.
Delegate the development/technical tasks to your tech lead/Sr Developer. Help/Suggest them if they are overloaded or lagging behind but don't impose your technical strategies. Delegate and delegate!
Keep everyone involved. Do not hide any information from team. Invite Sr Dev/QA/Tech leads to the meetings with clients(selectively).
Give importance to every team member. Involve them in decision making.
Finally, do all of the above based on the situations. Do not do everything all the time.
So...Manage all of this to become a good Manager!
The first thing to keep in mind is that being a PM has nothing to do with the skills of a developer other than to judge estimates and evaluate design decisions. It's a DIFFERENT job. You're not the developers' peer and you're not s super lead (anyone who says those things is telling you they just want to be left alone to do whatever they want). So, here's the simplest version:
A PM is responsible for WHAT everyone on the team is doing, a dev (team member) is responsible for HOW they will do the work assigned. That division of responsibility is not black and white but it's a good razor to start with. Anyone who tells you it's not a real management role or you're not a people manager is badly mistaken. Because the PM role in most companies wields authority through persuasion, you are the only true people manager there is.
As the primary conduit between the world outside the project (with its many, often conflicting, stakeholders), and the world inside the project (with its many, often conflicting personalities, styles, and levels of experience), the PM has to deconflict both worlds and harmonize the two. That means you will always have to choose who to disappoint at any given moment.
The job of the PM is to maximize the value of the project for the company. Everything else is secondary. Note that value, in this case, covers a lot of ground from economics to morale and increased capability to tackle the next project. Always be prepared to explain your decisions on that basis, and, if you can't, why are you deciding that way?
The final thing I would tell you to expect is to spend 2+ years at the role before you begin to become comfortable with it, if you ever do. You are either wired to be a good PM or you are not. The mechanics aren't hard, the social dynamics and the situational awareness are.
Another reasons to keep dabbling is that you may decide you don't like project management. If you work as a PM for two years without writing any code, trying to get back into development is gonna be much harder.
Lastly, as a code dabbler, don't try being a developer yourself. That's no longer your role. The occasional git commit to fix a typo or something is fine, but you don't wanna be that guy who is a control freak, always refactoring the code your team delivers. If you wanna write code, stay in development.
Your job now is to manage the state of the projects you're working on, and enable the developers on your teams. If you're coding, you're almost certainly not doing that to the degree you could be. The new job will be difficult. Change is hard, new skills are hard, and there are days you'll want to just go code something because it's easier to do and more fun.
Don't do it.
Your priorities are enabling your team and making sure that everyone knows and is on board with the state of your projects. In your new job, the way you succeed isn't by putting out code - it's by your projects and teams succeeding.
Make sure you like the sound of these priorities; if you don't, you should probably reconsider the change of roles.
Lastly, make sure that you understand what you're accountable and responsible for. Project managers don't (by default) have people responsibility, but at your company they might. Same question about doing product ownership, agile coaching, tactical team leadership, reporting, etc.
- Keep current on technologies, what your team uses and wants to use, and also technologies that might be useful.
- Know your developers' strengths and weakness, both technical and interpersonal.
- Time management. (Can't stress this enough).
- Ask lots of thoughtful questions (informed by the first item in the list).
- Develop relationships with other managers, teams and executives. If you want to manager bigger things, those guys need to see you and know you can do it.
- Don't hold grudges. At the end of the day, go home and forget about any bullshit that occurred.
- Trust your developers.
- Don't be afraid to say no.
- Take risks. Accept responsibility when those risks turn into failures.
- Give genuine praise.
One sort of cultural thing to keep in mind. It may not apply to you though. After moving to the Bay Area several years ago I noticed that behavior with organizations often defaults to passive-aggressive, especially when there's disagreement. Avoid being passive-aggressive and correct others (in a professional manner) when they're being passive-aggressive. I used to deal with more aggressive people when I worked on the East Coast. You know where you stand at least. PA behavior allows bad sentiment to stew and kills progress of any sort. Being assertive most of the time will solve this.
Scott Berkuns Making Things Happen: Mastering Project Management (Theory in Practice) details some of the less process-oriented, more in the trenches aspects to managing a project.
Steve McConnells Rapid Development: Taming Wild Software Schedules is more of an encyclopedia of software project management. Published in 1996, its now a bit dated, pre-dating Scrum and Agile but all those ideas have been known for a long time.
Most annoying thing : I can handle with some straight forward guys but not someone who fake like caring about you and your career, while actually fooling you. And remember those 'urgent' task needs to completed in late nights or weekends and no one cares about it for months, stop pushing people just because you possess some-kind of authority. Be transparent.
All the best!
- Encourage communication between different roles.
- Trust the developers. I like it when a project manager can talk code but in the end it's the people who are doing the work who should make decisions.
- Protect your team from upper management. Don't let senior managers assign work to your team members for their pet projects.
Product managers, on the other hand, deal with what gets in front of the customer, why, and when. I have more inclination to work with them.
2. Managing open-source-based codebase is vastly different from managing the closed-source one. Mixing both (a reality) will require special thinking and measures. It will require two very different sorts of developers and activities.
2) Rightfully Estimating TimeOverestimate keeping in mind shipping a feature is usually making it + testing it out a bit.
3) Know what features can be chopped off when push comes to shove.
4) communicate clearly and with as much supporting documentation as possible.We still can't vulcan mind meld. So as a PM you need to convey your prioritised vision to your devs. motivation, how a feature fits on the roadmap, dependent features, Screenshots/ mocks, process flows, test cases to check against, all this will make sure features shipped don't need reiteration.
4) Architect for longevity If you are working with an architect, he will probably be responsible for this. But remember, its ok to delay the initial stages of your product if you are spending time building up the core. Think build systems, continuous integration and deployment cycles, just the API layers and business logic, UI work happening totally independent as functional mocks etc etc.
5) Trying to stay away from the temptation of coding. Code when you need to, assign tasks to yourself as and when required but not as a norm. It takes a lot to see the bigger picture and keep track of so many moving parts of a project. Doesn't help overloading your system with dev tasks too. These two worlds are pretty different beasts.
PS: One tool which I relied heavily on over the last year was Omniplan. We not just tracked dev items, but also things like deployment timelines, adoption rate within the org, training schedules for employees and how all this tied up into the features which needed to be rolled at and at what time. A sample of dev wise sprint plan which helps people plan their workload , keeps meetings to the point, and lets people take vacations when they are relatively less occupied :) http://imgur.com/a/1b2mH
The best boss I ever had was an ex-Israeli commando officer. Most people look shocked when I say that. Here is why he was great:
1. There was never, ever, any doubt whatsoever what he wanted done, and when.2. When you told him what it would take to do that, he actually listened, and did what he could to smooth the path.3. He never left basic humanity behind for any reason in his treatment of team members.
make your eng peers do uninterrupted work, reduce meetings, cut the crap out of the corporate process.
This is not to say keep them in the dark about what is going on, but don't try to schedule a "sync" meetings, ever :)
Another thing that me and my PM peer did was, we had direct communication line. he could ping me anytime, and i could ping him anytime. We came up with ideas at odd hours that ended up making a good amount of revenue increase, but we also respected each other's time. I used him to get myself pure work time when people were asking for updates, and he used me to prototype many of these ideas.
it worked out really well for both of us.
I'm curious whether Google or Facebook have standard project manager processes and tools internally. I know Facebook users Phabricator, but they also user GitHub.
In my experience making a similar move, I initially made my gauge of success too dependent on others. I had to sit and think to create new metrics and measurements outside of what was currently done in order to show my success.
I always assumed PMs would ballpark things like Red/Amber/Green color codes and projections, but that "winging it" will only take you so far.
The big lesson learned from a somewhat chaotic first foray into management was record everything, and leverage that evidence in every decision post kick-off. This requires more disk space than my brain has, so my note taking and organization skills were forced to go through an overhaul.
My take away from him is be organized. If you have to oversee a lot of projects, lots of schedules, lots of people, you can't keep track of it all. Outlook, Onenote...find some good tools and use it well. Follow up promptly - you may need to deal with other teams a lot, and other teams won't put you on a top priority.
As a follow up as 'other teams won't put you on a top priority'...don't put other teams on a top priority :). Learn to say no when you have to. But also learn to say yes when you can. Your team may need assistance down the road and you want to cash in those chips.
Address the biggest technical risks early.
* The Mythical Man-Month
I can't think of better books on managing software projects and software developers.
Every once in a while you can participate in some technical discussions but ultimately now you are responsible for them happening, not necessarily happening with you.
You know the nitty-gritty and every detail of how a piece of software is made. Use this to your advantage to make developers you work with feel safe. You've been in their shoes before, you aren't going to change requirements last minute. You aren't going to come to them with an incomplete spec and demand unrealistic outcomes. When your bosses are setting the stage for disaster, you're going to fix it at their level before your dev team even hears about it.
However, don't fall into the trap of discrediting what the developers you work with are saying or doing, because you have the experience or know more than them. Be humble, and believe in your team. Gain their trust, and make sure they know they can come to you with their problems, mistakes, and questions early. They'll warn you when something is going wrong before anyone else even notices it (instead of keeping quiet and going along with a bad idea). They'll tell you the real reasons why they're pushing back, while they give other PMs excuses they think are more likely to get them what they need to succeed.
Your primary job is no longer product or productivity or even shipping. Your job is to get the best work out of the people you work with (even the people you work for, not just those you manage). Most of the time, the problems you fix are communication problems. Most of the time, everyone means well but doesn't realize when and how they're shooting themselves in the foot.
Momentum is everything. Don't let anyone place anything above your team's momentum. Become a firewall between criticism and productivity. Internalize critical feedback, but be careful about when and how you bring it to your developers. Sure, there may be rough edges on your product, but every time you tell your guys they're screwing up, you're sacrificing project momentum. Finish a rough draft of your product, celebrate the victory you've earned (now it's 80% complete), and motivate everyone to polish off the rough edges after thanking them for their hard work.
It's your job to celebrate every minor victory and be that guy (or gal) that emails the entire company to show off something a member of your team did. Not to make yourself look good, but to motivate that person to give a damn the next time doing the right thing means working hard (when nobody is going to notice).
Also, don't write any code and don't do code reviews. Keep your skills sharp by building MVPs, doing technical research, exploring APIs while the spec is being written, etc. Don't step on your team's toes by micromanaging & nitpicking with their code.
Be nice if you didn't pull that shit.
You will have to learn how to delegate. Give people the opportunity to fail. Even if someone doesn't seem like they can do a particular task, give them the chance to learn, and give them the resources to learn.
This goes into always remembering to protect the future of the project. You'll receive tons of pressure to do "quick fixes" and "just brute force it" and other bullshit management lines, a lot more than when you were just a developer. It's your job to be a shield against upper management for the sake of the project. Don't short-change the long-term viability of the project and your team for short-term gains.
I've seen many environments which have project managers that aren't needed. Very capable people are then relegated to noting status updates and pressuring the team to meet deadlines. That way lies misery for all.
Agile has done away with a lot of these positions, however, environments that are highly complex with long term activity and/or many stakeholders to coordinate may still warrant the role.
With that said, I am not sure if the solution you propose fixes that. The small group of curators would just providing a new perspective, probably not one that liberals and conservatives would both like. This is after all what many existing news sources already do. The key is in the group of curators. Maybe a well known group of liberals and conservatives could work on the stories so it fairly addresses the perspectives of both sides?
- If it is something really relevant it will appear on HN front page with a very short delay. Then, by reading the comments and looking for different points of view, I can form an opinion as unbiased as it is possible to get.
- In addition, for weekly digested news, I can read the Economist.
It's going to be tough to overcome that.
This is a hard problem I think. Sometimes news that is interesting and popular is also controversial or just click-bait BS, so you have an ethical vs. interesting news dichotomy. Day-old-news will probably not be interesting to people who already read and discussed the topic the day before. Also consider that if only a few people are curating it there will be other discrediting flaws that might not be caught until more readers see it.
Also, keep in mind that if users get sick of the same kind of articles being posted (which could likely happen given biases of the curators) instead of blaming the users for upvoting (like on HN) they will blame the service instead and will likely stop using the service altogether.
Edit: I could see this working with a small group of individuals that are like-minded to the biases/opinions of the curators.
I just had another an idea about something tangentially similar just a few minutes ago. It'd be algorithmically curated news with no human intervention: https://news.ycombinator.com/item?id=13284875 . Do you think this would be somewhat related to what you're talking about?
If you want to launch a new one and be successful, you'll have to find a way to stand out from the crowd. That's probably going to be a "bias" of some kind, or at least a particular philosophy you intend to bring to bear through your commentary.
For example, I would be interested in reading a blog that reports on the news through the lens of black swans and antifragility (see Nassim Taleb's books). It's something I haven't really seen done well.
Bias is not something you do on purpose, it's something you have to work very hard to avoid.
Not worrying about fuel, oil, etc is great and turns trimming from a proper "job" to "Ill just do a bit of trimming while waiting for dinner". It has been one of the biggest and best improvements to our daily farm chores in years.
It was a novelty, but for the price it was a very good novelty.
It had problems though. I found that the device tended to get confused about my original facing. So straight ahead would eventually mean turning my head. I'd have to shift around to avoid straining my neck, but it didn't really help because straight ahead would just continue shifting after a little while.
I don't use it much, but it was definitely the coolest thing I got.
I spent countless hours reading all the articles bashing Apple for it, and finally concluded that much of it boiled down to the fact that it was an expensive machine for the specs it delivered. And that is undeniably true.
But I stare at the darn thing virtually all hours I am working and a significant chunk of my leisure time as well. The reality is that for my actual computing, things like weight, battery life, how the keys feel, the screen, etc., matter far more in my enjoyment and utility of the computer, and on that measure Apple continues to knock it out of the park. I got my first MBP because of the retina screen, and soon thereafter realized I could never go back to using a device with a lower pixel density. I kinda feel the same with this machine when it comes to color: It is just stunning. Given how often I am looking at it, that dimension alone made this purchase worth it IMO.
The Touchbar has in fact mostly been a gimmick, although pairing it with BetterTouchTool has actually been extremely powerful and I've come to use it more and more.
Call me a vr believer now
Some of the technical complexity comes from the sheer diversity of data sources and sinks. The infrastructure is also non-trivial.
This is somewhat future looking because most large startups have a data team that builds their own in-house system eg Airbnb, Yelp. However a lot of companies don't have that luxury and extracting value (patterns and insights, for example) from your data is useful for many businesses.
That's right! This problem is so hard that NOBODY can claim to have figured it out. And I haven't even gotten to the market size--the potential market size is literally the entire humanity! Not everyone wants to share what they had for lunch, but EVERYONE wants to get laid!
Hope this answers your question!
But my resume wasn't bulletproof (decent school, some job hopping) and I didn't express the requisite awe about their product or technical tasks (I gave my assessment that they have a good business plan but should expect modest growth, and the engineering tasks needed would be tedious to anyone honest). That's all I can think of, because I sure as hell didn't answer any questions incorrectly.
Also, for all my efforts, they ghosted on me afterwards.
What you are describing could be attributed to a component of SV thats long existed. Ageism.
I went through something similar. As a self-taught software engineer with a business background from a not great school, the hiring process at most large companies is specifically built to prevent people like me from getting in the door.
What you are encountering is the "gatekeeper layer" of these major tech companies. I call this "the front door." To put it mildly: The front door of tech is configured to reject everything that doesn't match some unrealistic perfect ideal of a genius savant engineer. To summarize Gandalf's general disposition towards flaming Balrogs:"Thou shalt not pass!"
Why is the focus on rejection and not acceptance?
There are three reasons. First, everyone wants to work at Google, Facebook etc. and there are a lot of unqualified people coming in. Second, these companies can't afford to grow at the rate at which they can gain talent. If Google were to hire a tiny fraction of the people applying to them every day, they would rapidly grow far beyond a size which makes sense. Third, they are very strategic about which directions they plan on growing in. They would rather acquire talent in groups focused in strategic topics like automotive than bother letting in single general-purpose individuals based on some brain teasers. Fourth, the actual volume of truly qualified people is even too high! The big companies can't afford to hire every qualified person who actually wants to work for them in some cases.
Therefore, anyone who possesses a diversity of skills beyond pure programming should completely avoid the front door, it isn't going to value your whole person (as you have seen).
Instead, you need to be using the "side door." That means you go and find people who you like (want to work with, resemble, build interesting stuff you like to use) and approach them personally and sit down with them like a regular human being and talk about building cool shit together.
If you are really great, people will recognize your greatness and they will help you get in the door.
Using the side door is about creating your own interview process rather than letting someone else define your interview process for you. Shoot high. Pick people who can hire you or have influence directly over hiring decisions. You don't need the gatekeepers.
I believe one or more of following factors are at play, keeping in mind that one company would not be the same as next:
- people have high bars for experienced hire, you can't just be smart and get things done, but also be able to wow the hiring manager/committee in some way.
- related to point 1, someone with 5 years of experience will have a difficult time evaluating someone with 15.
- if engineering expertise is hard to interview for, leadership skill is even harder. And companies are definitely more cautious when hiring for leadership roles.
- there are a LOT of people wanting to join those top startups, so competition is fierce, and there is less pressure to hire a good but not amazing candidate.
- interviewing is a skill in itself, just because you had so much experience does not mean you can ace interviews without preparation, especially with high expectation/competition positions. You should sit down and think hard how you can best demonstrate your experience in an interview.
- lastly, it's actually quite easy to fell into a good job that makes getting next one harder, especially if that project was a failure, or uses an outdated technology.
>>> The things I think are hurting me are that I'm not great at whiteboarding
I don't know about that. I have a friend who stopped an interview when asked to whiteboard and instead referred the panel to review github together, they ended up hiring him.
>>> it's hard to summarize the scope and impact of what I've done as CTO growing a team from 2 to 16 engineers
That is more likely to be the issue. Find a way to explain your value, what you did, and what you can do.
When explaining your accomplishments, put them in context they can understand. This isn't technical specific (unless shared) but rather at the more abstract (business) level.
There's the interview kickstart guy on here too. He runs a course that gets you in shape. You get interviewed by employees at the big companies which can only help. Triplebyte here also does a pre-screen for YC companies.
The couple of things I saw that inspired this:
An obvious example of this is when I search for "Django" (I am primarily a Django developer). DuckDuckGo will return results about the film as the top hits, whereas Google already knows that I mean Django Web Framework and will return those as the top hits.
I appreciate the fact that my searches are anonymous with DDG, but I doubt that it will be able to be "as good" as Google for that reason.
Well, no, they don't even have their own search engine.
> a search engine's results are only as accurate as the number of users who search and contribute to it
That makes no sense. Anyway, we don't use DDG because its results are shitty.
1) Many people don't realize that tracking isn't just about having something to hide. But, it can cost you money. From Airline tickets to staplers you pay based on a profile:
2) People don't realize what's being tracked. I usually send them to http://history.google.com/history to have a look. Or http://webkay.robinlinus.com/ to see what their browser can access. That makes a lot of people realize just what is out there.
3) People feel they can't search without personalized searches.
The example is often a matter of disambiguation. For example, if I type "Python" I want code, not snakes. But, really, when is the last time you only typed 'Python' and wanted something generic about Python? You probably wanted a package lookup or the latest news on a release. So if you become more specific there is no issue.
Plus when you get a bit more specific on Python you can trigger things like package lookup:
Or NumPy Cheatsheet:
At the end of the day some people may truly be ok with all the tracking that takes place, and that's ok that's up to them. But, at DuckDuckGo our goal is to educate people on online privacy, and provide a trusted way to access information as best we can. (Not to mention Instant Answers and Bangs which are super addicting)
Google did not become huge because of the search engine alone. AFAICT two things, based on related technologies, made Google oodles of money: AdWords and SERP ads. (AdWords used to be so unobtrusive I never tried to block them.)
I don't know how DDG currently pays its bills. They do feature unobtrusive and clearly marked ads on their SERP, too.
I'm not sure if ads can be reasonable without precise targeting, that is, tracking, tacit privacy invasion of various sorts, etc. Poorly targeted ads are disliked both by users ("dumb!") and advertisers ("poor conversion, money wasted").
The only other option I can see for a private company is to sell a subscription. Pay n USD / mo for no-tracking, no-strings-attached search.
The question is, of course, the value of n. It may turn out to be uncomfortably high for many users, just because advertisers value their eyeball rather highly.
You can already opt out of ads on some Google services, e.g. YouTube: try closing a few ads, or visit google.com/contributor when it (re-)opens. You can opt out of personalized ads, too. While many of us still won't trust all these measures, for many these would feel adequate.
I wish DDG all the luck. But being and staying an alternative, privacy-respecting search engine, even a low-profile one, isn't going to be easy.
For 'easy' searches it's equivalent to Google.
For 'hard' searches it's nearly stricter better than Google, because if DuckDuckGo doesn't find something I also look at the Google results (append !g to the search), and they often come up with very different subsets of the internet.
To me it no longer has anything to do with privacy or not liking Google, it's just that DuckDuckGo has the better product for putting into your search bar.
It's much nicer about disambiguation than google, and can be incredibly helpful. e.g. Search for Zen - you get a wide selection of possibles in probable order. Sadly there's far too many missing. Crowdsourcing needed.
It's horrible at localisation. eg set Filter by region to UK and search any global multinational. Chances are the UK site is WAY down the list and the .com and US options hard at top. on google UK the local branch is always first.
There's too many instant answers that presume a US only view of the world.
The instant answers when they have adequate data and ! searches are brilliant.
Lyric and video searches are orders of magnitude better than Google.
Maybe 5% of searches go to Google as I'm not quickly finding what I need.
Oh, I wish it was called something simpler like "Ducker" or "Duckit", but whatever, bikeshedding territory.
On that note, any good alternatives to G-Suite that aren't necessarily Microsoft O365 (though I'm not against migrating to that either). A straightforward email migration is a big plus, documents not such a big deal.
Search engines are such an important tool that I would be more than willing to pay $10 a month for a good quality one with strong commitment to privacy and maybe additional premium features.
I 've given it a few honest tries this year but the results are really not that great, certainly far inferior to Google's or even Bing's, and it 'feels' slow -- but then again, a few dozen ms slower than Google is 'slow' to me (and I am sure the difference is higher than that ).
I suppose the major selling point is that it doesn't track your queries and that's nice and all, but it definitely is not important enough for me to trade that for better results and responsiveness.
I wish them the best though.
If they become bigger than Google what's to stop them from becoming another Google?
Why punish myself by using an inferior service just to give it the seat at the big 5?
French technology which work really well !
...but that being said, DuckDuckGo ain't it. It's in fact, quite far from it. It's roughly as good as old Yahoo Search (pre-Bing), which also nobody used because Google's is vastly superior.
Give me a search engine like Google circa 2010-11 (back before the menagerie of Bird algorithms began trading "fuzzier" results for raw search power) and I'm good.
Started using Beaker Browser as my main browser, DDG as my search, and am working on moving the rest of my life off google (read: gmail).
Also have been messing with doing more work on a raspi tablet rigged with a bluetooth keyboard/trackpad combo.
If you use it how are the results?
And putting aside the quality of results, the actual design of the site is not very good. This is probably a preference, but I find it much easier to quickly scan a Google results page (or even Bing), but DuckDuckGo, with the font face and spacing they use, is not as clear.
1) Why do you think their results would get better if more people use their engine?
2) If their results really are better than Google, as you claim, why is their user base so small after all these years?
3) Why should we trust them any more than Google? How do you know they're not actually collecting your data or passing it on to the third party engines they use?
Call me crazy, but I suspect that's part of the reason DuckDuckGo has had a hard time catching on. A name matters.
If I was DuckDuckGo I would rebrand to something simpler that could be used as a verb. But what do I know?
Are there not privacy concerns about this for DDG?
>Yet they do store a cookie by default - this cookie is called "user_segment" and is valid for 1 month after it is first set.
They have removed it but this kind of behaviour doesn't exactly raise trust. Also they are based in US so 'privacy' is just PR.
I would recommend to use startpage.
I am at a loss to understand really why 'us' should start doing this 'more often'. Is there something inherently good about using ddg vs. google? Why should anyone use it more vs. what they have already decided works best for them? This smacks of 'make the world a better place by using ddg' unfortunately as many others have noted it's simply not a better mouse trap. And what does the name have to do with it at all?
I maintain a blog where I "showcase" the best bangs for the Duck: http://duckgobang.com/
His boss begged him to stay -- he could even work remotely. My friend took the deal. He lives in Charlotte now and flies to LA every 2 or 3 months.
The best place to look for remote jobs is to talk to people who have worked with you in the past and trust you.
I have for the 2 years, applied to 100+ jobs a week. When I don't have work or when I find my current work teetering off, I sit down every Monday, go to 40+ job sites I have collected over time and just apply to as many as possible within the 2 hours or so.
Its hit or miss, but I tend to find something within the month, someone looking for part time remote work.
I am always looking, but since its part time, I get filtered out a lot due to employers wanting full time folks.
Just Hustle. Keep Hustling. Don't stop hustling. It helps me.
Following are some of my impressions but they are subjective and perhaps a bit speculative.
Generally I've found that the attitude of most US companies is that if they are willing to hire remote, they are usually only interested in hiring candidates inside the US - even if they are a native English speaker (I was an American living in Vietnam). This is very different than the attitude that I've gotten talking to a companies in say ... Singapore or Germany.
Another thing that seems to happen is that some companies seem to throw the REMOTE OK tag to their posting without considering whether or not everyone on their engineering team is actually ok with working with a remote employee. I've done several interviews with teams that were REMOTE OK but had no existing remote employees. Usually it only takes one person to veto a hire. That's something to think about if they are looking at both local and remote candidates. Unless there is a really compelling reason to hire remote, usually they will go local (makes sense). You might not even want to work with one of these companies because they aren't set up for remote work... communication takes a bit more work from all team members - not just the remote ones.
Overall I've had a much more positive experience with the HN: "Who's hiring?"" thread than anywhere else. I think this is because the first point of contact is often an engineer and not an HR person. My resume is a bit odd and doesn't have a BRAND_NAME_SILICON_VALLEY_COMPANY or a BRAND_NAME_UNIVERSITY so it bounces right off the HR department. It's very helpful to be able to talk technology with someone in the initial conversation. If I can get a knowledgeable front-end engineer to look at some of my previous work, then I usually get to the coding round.
I had no luck with any of the remote hiring sites: remoteok.io or weworkremotely.com. YMMV
Ultimately getting a remote job seems to come down to:
1. Having some kind of portfolio to demonstrate your competence.2. Doing as many interiews as possible. Also the more interviews you do the better you get at it.
The focus should be on increasing your skills, making them more unique and super necessary for employers.
And then use the relationships you have already (eg current employer or clients) to start working remotely.
* http://news.ycombinator.com (monthly posts for freelance jobs)
* http://dribbble.com/jobs (only design)
* http://getonbrd.com (latam)
Here you apply as a professional, they approve you (or not) and then assign you projects.
I do not recommend
Interact with other freelancers. Usually you will find a #Jobs channel.
* http://join.nomadlist.com ($25 month | $75 year | $200 lifetime)
* http://workfrom.co/chat ($5 month | $50 year)
* http://freelance.chat ($25 lifetime)
This list is from an article  that I wrote, hope can help!
What kind of remote jobs are you looking for? Tech or non-tech? I've generally found weworkremotely and the HN hiring thread to be among the best. If you're interested in remote jobs at startups, AngelList have a special collection for you https://angel.co/job-collections/remote/
It might be worth your time to look through http://nodesk.co/remote-work/ for a collection of remote job boards (it's a list so visit them all and save the ones you find useful) as well as http://workintech.io/ (job boards specifically geared for tech jobs).
Let me know what you're looking for and perhaps I can help point you in the right direction.
Otherwise you could seek employment at a place known for having primarily remote workers.
Contract work and freelance is also easy to remote.
I learned Python and it made me enjoy writing software again. 8 years later and it's nearly the only language I use. In principle it makes more sense to choose the right tool for the job, but if I don't enjoy doing the job with other tools, it makes sense to plan around the tool.
I avoid mobile or front-end web development because Python isn't the right tool for those jobs. Fortunately, I like server-side development and data engineering and Python fits perfectly there.
Want to build an operating system in Ruby? Ok, good luck trying to pour concrete with your tablesaw.
Admittedly, that analogy is a little extreme since programming languages are Turing complete, etc etc. However, if that's your perspective, you may want to have a gander at Cobol on Cogs: http://www.coboloncogs.org/INDEX.HTM
First of all, is this a solo project or is a group of people going to be working on it? If it's a solo project, then you are far less constrained. If it was a small proof of concept or otherwise throwaway project, I'd probably use it as an opportunity to try a new language. If it's a real deliverable and doesn't involve hard real time performance, I'd choose Haskell because it's a language with which I'm proficient and I enjoy using.
If this project is going to be developed and maintained by more than just myself, then the story changes. With an existing group of developers, you have to play to their strengths and get buy-in, so use either a language they already know, something similar, or something they've shown an interest to learn. If you don't yet have developers, consider the difficulty of hiring for certain technologies. There are also performance and correctness requirements to consider.
If you happen to be an enterprise decision maker (which is unlikely since this is a community for intelligent critical-thinkers) then the only correct choice is Java. No one gets fired for choosing Java. There's a framework for everything. There are plenty of cheap developers. It's popular, so it must be good.
2) Does it suit the nature of the problem?
3) Does it have a large enough ecosystem to address my/our needs?
4) If it doesn't, do I/does the team have enough time to fill in the holes?
5) Can it be deployed in a reasonable way?
First, what is the type of project? If desktop, then C#/WPF (since my desktop apps will always be Windows). If web, then the choice becomes more complex.
For web, am I going to be solo? If so and there isn't a compelling reason to pick a specific language (be it because of its strengths in a specific area or environment constraints) pick whatever language I feel like learning or already know (if it needs to be rushed then pick a language I know).
If I'm doing web and going to have a team, then pick something that I find interesting, that fits the needs of the project and I can find people if need be. I'm currently working on a project that is just me but will eventually be a team of people (somewhere down the road). I chose Elixir/Phoenix because it is something I want to learn and there is no specific reason for picking some other language. I've heard enough about Phoenix and Elixir to know that I could find some Ruby/Rails devs to teach them Elixir/Phoenix if I wasn't able to find elixir devs, so making a team isn't a big deal.
- How complex is the thing I wanna do? If it's very complex I'll go with Python since I'm much stronger with Python than Go. This allows me to focus on the problems I'm trying to solve not the ones I create by misunderstanding something in Go.
- What are going to be some of the key features I'll need from my tools? Concurrency is not a strong point of Python so something that requires it may be better off in Go. Am I going to need auth, email sending, an ORM? Django is great for getting that crap out of the way so I'll probably use Python.
- How much new stuff will I be learning for this project? Most of my personal stuff is done as a learning exercise. I have found in the past I tried to learn too many things at once and I would just end up lost.
These are just some of the things I think about before choosing a language. However, your milage may vary of course. What ever questions you ask yourself you should always keep in mind the strengths and weaknesses of your options and whatever you do end up choosing you keep those strengths/weaknesses in mind and work to make the most of the strengths and use other tools/processes to mitigate the weaknesses.
Does the project involve certain functionality that's already been solved in a framework or library available only in one language (or at least not in any languages that my team and I are already proficient in)? Will it be faster for me or my team to learn that language thoroughly than to reimplement the functionality?
Is the project being implemented on a platform that only supports a limited set of languages officially (e.g. iOS or client side web development)? Pick the most widely used of those.
Otherwise the project gets done in the language I enjoy most and am most proficient in (for personal projects). Because that'll be the most fun for me.
Or the language my team collectively knows best and were hired for their knowledge of. Because that makes knowledge transfer and future maintenance easier.
I've used Perl and Python for small applications and glue code. I liked Perl for a long time, but I don't want to go back to it after using Python.
Most of my personal projects are written mostly in C++, sometimes with bits in C, because they're suitable for emulators, game engines, renderers, Arduino programming, and robot control code and because (as previously stated) I like working with them. I've been meaning to start some things in Rust, but haven't gotten around to it, in any serious kind of way.
I choose employment based partially on what language they're working in. Systems-level stuff on Linux? Probably C or C++, so I'll probably be happy.
You can keep it simple.
1. Your time 2. Machine time 3. Others time
Balance those three to find what works. Need really fast code? Sacrifice your time and co-workers time. Need really maintainable code? Sacrifice your time and machine time. Need really quickly written code? Sacrifice machine time and co-workers time.
2) use java
The reflection part I could have gotten around fairly simply, but I'm happy with how cleanly it worked with reflection. Polymorphism was a must-have, and garbage collection was close (it might have doubled the amount of work if I didn't have it).
Otherwise C# is easy and reliable. Less secure than Rust, but less of a concern if it doesn't face the web.
It's a myth that in order to be a good software engineer you have to spend every free moment coding or that you need to be an open source contributor.
It's also a myth that all or even most employers will ignore or ding you if you have no contributions.
If you want it enough for yourself and for its own sake, schedule one evening (or weekend afternoon) a week for it - just as you would schedule one evening a week for date night or for volunteer work or for anything else you care enough about. Treat it as similarly inviolable.
That goes for anything outside work you want badly enough - learning to play the flute; writing a memoir; whatever.
You should ask your manager. First identify what you'd work on, then make an argument for how improving it would be good for the company as well as the public, and finally (if needed) try to sell them on the PR and recruiting benefit to the company. Propose a specific chunk of time for it, so your manager doesn't have to worry about you disappearing down a rabbit hole. (I might suggest the last 4 hours of the week, when not much gets done anyway.)
If you work for a larger company there may be policies around this, and they are likely to make it more difficult. But as a developer, you only need your manager's approval.
If you work for a smaller company you'll have a much easier time selling the idea. And if it's really important to you, consider working for a company that actively supports this.
I have a full time job and two small kids. I'm usually out of the house with the family on weekends, and after work, I sometimes play video games or read manga. I rarely ever attend meetups or hackatons because I live and work uptown and frankly don't have time to be driving downtown.
Yet, I still find time to work on my project (usually after the kids have gone to bed). I used to also do it on the commute when I took transit to work.
There's really no real secret to doing open source. Working on my project is something I truly enjoy doing, so I often "stew" on problems and next steps while driving or eating or before falling sleep, and on the nights I feel like working on the project, I just sit down and do. If sitting down to do open source feels like a chore, then it probably isn't for you (and there's nothing wrong with that!)
Like anything else that might get stalled by procrastination, every time you sit down to work, you just have to pick some small thing to complete, so that you can get into a roll.
Working on open source to scratch an itch is also a good way to incorporate open source into your day job.
There is no shame in not contributing to open source - most developers don't do much beyond using it. There is also no shame in failing to bring new insight. I would say that make sure that it is something you enjoy doing, because otherwise it will tax your mind some to force yourself to make the effort.
Did tons of open source at work. A bulk of my open source early on was fixing gulp, grunt and jquery plugins that would often break when API's changed.
To get your foot in the door, start by patching other people's projects. That can be as simple as a typo or adding docs initially.
On any project, the first thing I do is almost always low hanging fruit. I clone it and try to build it from source on OS X, Debian, FreeBSD and fix anything wrong with the build system or tests. Often just right there I can get a few patches in or segue it into a larger fix  
I built up from doing small stuff to then doing big things, and eventually my own projects like tmuxp . Small stuff means you get an opportunity to lurk and understand the codebase, tests and contribution guidelines.
You can also find a mentor. Open source programmers are always looking for a protege who is passionate about the codebase. Hang out on IRC with them and say hi. Look at the milestones to see if there's any quick wins to get started with. If you work at a company that uses the project, be sure to mention it. :)
: https://github.com/python-cmake-buildsystem/python-cmake-bui...: https://github.com/aseprite/aseprite/commits?author=tony: https://tmuxp.git-pull.com
I'm not going to work on anything remotely work-related in my spare time, though. I'm not interested enough in the work I do for my employer to also make it my after-hours hobby.
Also, I'll often briefly open up some code at work while I'm eating lunch just to get my mind going on it. A quick scan of the structure allows me to then break away from the computer to walk/think/socialize while my subconscious mind chews on whatever the problem is. Whenever I find a free chunk of time, I'll already have a rough idea of what I can do to push that needle forward. It's then just a matter of doing it!
Also, one my clients is interested in open-sourcing one of my projects. I'm excited about that, but it's not the same as "finding the time."
It does not matter if I am unable to finish a task, because I'll be working on it during the next hacker space meetup. Yes, oftentimes it is slow going, particularly when we're having fun, but it gives me two clear structured time slots a week to work on my projects.
usually around dinner time (before or after dinner).
my problem is not that I don't have time, but that I don't have a focus. I do a little bit this and that.
From experience, you gotta learn that language is like a filter through which ones' mind/heart/intentions are shaped. Then, you master getting into the pre-language state of mind that has no language, and from there you train yourself to see the world with a different organization of concepts.
First, learn the 200 most common words in the language.Do whatever it takes to learn all the verb conjugations.Spend countless hours listening to real humans talk in conversation and repeat exactly as well as you can over the tracks whilst listening (like singing along to a song) so you can master the ups and downs of tonation in pronunciation.
Top 2 tips:One) 15 minutes every day is worth so much more than 150 minutes in one day every 10 days. Meaning: frequency is key, and quality over quantity.
Two) to truly become "fluent," that is, to make the leap from "this is something I can use" to "re-experiencing life through the frame of a German person / Japanese person / Swedish person / whatever" you must spend time in a place culturally saturated in the language.
That said, you can spend 2-3 years of your life immersing yourself in radio, news, television, movies, and learning mnemonic methods (whacky stories and images that help you retain meanings) and make incredible progress.
But outside of that, there are some great suggestions. A few things I have to suggest:
Get ahold of some of the books and workbooks for adult learners. This is an easy way to learn grammar and common phrases. I'd use these in conjunction with other things.
Next, watch children's cartoons. Here (Norway), adult films often simply have subtitles and leave the English audio, but children's shows are dubbed with simple words and clear language. It is a bonus if it is a crossover - I watched many hours of "Spiderman" cartoons in Norwegian.
Read books, especialy ones you've read in English. Harry Potter, for example, is available in multiple languages. It'll be difficult at first, but you'll increase vocabulary from the repetition in the book. Terry Pratchett is another choice for German, at least (I can find some in Norwegian).
For speaking, Skype is popular for tutoring and speaking practice, though you might have to pay for this.
Good luck :)
If you're not in Germany or Russia, get a teacher with a small class. Mine was 4 people so we could speak and exercise a lot.
I've been doing Duolingo's French lessons every day for 15-20 minutes during my commute to work. I find it quite engaging and useful.
The first book I read was Beauty and the beast in french. It's a short story to start with. It took me a long time to just read some sentences with proper pronunciation and I'm still working on it. I look up youtube videos for some extra info. The frenchpod101 videos are good. I guess you might have already tried these, but just wanted to mention it anyways. Hope this helps! Good Luck!
A lot of language learning exists below the "level" of words and sentences. The sound of a language.
And even when you progress to words and sentences, phrases, idioms, and the like differ. Gender exists, or differs. Native speakers don't memorize these. They learn by absorption. You are fortunate in that, with today's connected world, so can you.
P.S. The rest of it, e.g. working through texts, tutoring videos, and all that, I leave to you. Just remember: EXPOSURE. And that you can't and shouldn't try to consciously process and monitor it all. Steep yourself in it, and let your whole mind (including sub-conscious, or whatever we're calling it) process it.
P.P.S. Approach it this way, and you will find that some of the "much harder than when a child" belief doesn't actually really of fully apply. I became conversational in French, starting from zero, in about seven weeks when I was 22. In the middle of Vermont.
I don't think this trend will last, though. If a user denies the notification request then the site is never allowed to ask again - the user has to manually enable the permission. People are going to learn quite quickly that if you don't put the request in the context of a specific action you're screwing yourself over.
That said, I wouldn't mind it if these prompts could only be shown in response to click events. Small downside, but it would stop the request spam quite effectively.
Perfect for the end user. Not so perfect for the spam industry, of course, but whenever those guys get to decide how something on the internet should work it always turns ugly, so that really has to stop.
Select "Do not allow any site to show notifications"
Myself, I find this just as bad as the constant overlays asking for you to sign up to a mailing list. I use the 'Behind the Overlay' extension to kill those, but I'd like something that prevented them appearing in the first place.
Are these things so effective that everyone uses them?
What kind of notification? How does it work? When/where will I be notified? How would I turn it off?
This news site is showing a custom popup to ask for permission and blocking the content.
-  https://webmasters.googleblog.com/2016/08/helping-users-easi...
There's a 'silent majority' effect when you measure the impact of a feature that increases engagement.
Imagine a feature causes 50% of users to immediately read another article and the other 50% to never return. That may look like a win after 2 weeks of testing, but the long-term effects on your business can be iffy.
I'm amazed so many sites have this feature, because it was an absolute nightmare for me to get it working alongside Google's sw-precache library.
You could turn it on / off when you just want to browse Facebook or whatever site without the notifications and that tiny red badge nagging you away from what you're doing.
Slack's Desktop app is built on Electron, so it's a second installation of Chrome anyways.
Ask to send notifications,
Ask to use your location,
Say something about you not having the SharePoint plugin or asking permission to use it or something like that?
Alt-N => browser pop under:
[offers notifications][show all][show some]
Or maybe just some icon in the url bar ?
People of HN: sell your dev skills for money and invest the money in assets that appreciate!
You may have bought domains that were used for spamming before you had them. If so, you can contact Spamhaus to be removed from the list. It'd be a better use of your time to just get new, non tainted names, because if Spamhaus is listing them so are many others.
Realistically it's more likely though that you yourself are the spammer. For instance, you bought some new domains, started blasting out emails advertising them and found out your mails got blocked for spamming. There is no solution for that apart from stopping spamming.
I would also checkout this talk: https://vimeo.com/147806338
It's pretty long but it's pretty funny and should give you some things to think about. There aren't any technical examples or demos but it's a good high level talk about the balloning size of web pages.
A good example of this is the homepage of t.co which clocks in at 3.08 kb and yet looks fantastic.
Also, communication is a big factor in hiring a freelancer. If you are outsourcing something to someone in another part of the world, watch out for timezone differences as well as making sure the person is a good communicator.
It's also just good general advice to always have them invoice you, just so you can have it on record for tax purposes.
It's now at around 2500 daily active users.
EDIT: Working on a product for a community I was part of was definitely what helped me succeed. I worked on the problem I was familiar with, and I received a lot feedback and support from other people. It also helped me stay motivated. :)
A little later, in April, I sat in mission control and helped launch a spaceship to the ISS.
Along the way, I realized:
Engineering in the real world is maybe 30% calculations and typical "sciency" work, the other 70% is documentation and communicating to people. The day-to-day in the aerospace industry is way different than the way things are taught at school (from an EE perspective). It's impressive to me how much design happens in everyday back-and-forth conversations, versus the common image of "one guy, hard at work, cranking out equations at his desk".
Being smart isn't enough sometimes -- you need to have discipline as well, and even then, there is a considerable amount of luck in the mix. Getting the timing for a presentation, or a forcing a decision at the right time, can make a huge difference in the success of a program. You kind of have to check all three boxes to max out your success counter: smarts, determination, and luck.
I decided to try to build a hardware company without raising VC --- which is probably one of the hardest decisions you can make. And required about 30 people to make a reality.
But now that we have finally got our manufacturing and supply chain working, I've been building our sales & marketing team --- and I can't wait to see how 2017 progresses :)
In February, my wife was admitted to the hospital, 25 weeks pregnant with twins, because one the babies was not getting enough blood flow through the umbilical cord. The doctors were hoping to get another week or two before his condition deteriorated to the point that delivery was necessary. Things did not go downhill as quickly as expected, and we were able to put off delivery by two months, to 33 weeks (technically one day shy...). While this was a huge blessing, it still meant my wife was in the hospital for two months, leaving my as a 'single parent' of our three year old, while still providing the support my wife needed (spending two months in the hospital is pretty rough on anyone, let alone someone coping with the stress of a high risk pregnancy).
Our sons were born 7 weeks early, weighing 3 lbs, 14 oz, and 1 lb, 13 oz. The bigger one spent three weeks in the NICU, and the smaller one was there for almost two months (coming home just before his original due date). So, at one point, we had a three year old at home, a newborn at home, and a newborn at the hospital (and my wife still recovering from a c-section).
Everyone is doing well now (the little one is lagging behind his 'little' brother (younger by 1 minute), but still within the normal range, and on the right trajectory).
So, my greatest accomplishment was managing to set aside more or less any concern I had for myself and spending every waking minute, for four months, either working or taking care of a family member. In the process I learned just how fortunate I am that, generally speaking, I have a tremendous amount of freedom in how I spend my time. Being in a position where every moment is consumed in the care of others is exhausting, both physically and emotionally.
Our motto for 2017 is "It'll be what it is"... (why tempt fate again?)
As of today I weigh 319 lbs -- from a peak of over 400 -- and just a hair over half way to my goal of being at 240 lbs. This is the biggest change I've ever made in my life, and I couldn't be prouder to have come this far.
Lesson learned: Even engineers have to face ethical dilemmas.
What I've learned:
1. Not all rules matter. A large part of my business is stretching certain rules, either from the marketplace, or from the source (e.g. a store that doesn't allow resale). That said, you can't get away with breaking rules unless you have a very good understanding of why the rule exists, who's motivated to uphold it, and generally what the risks are. Don't screw over customers.
2. There's a lot more to be made by taking risks than there is to be lost. I've easily lost over $1k multiple times in various ways, but when I "win" it's to the tune of 10 or 30 times that. Take smart risks, only where the realistic upside justifies it.
3. Be willing to pay for information. There are courses out there in almost any topic. Personally I've largely carved my own path and paid very little , but I'd still recommend courses for others. Also read a lot of whatever free information is out there, and network with people who have more experience.
4. Don't do too many things at once. It will kill you. I've been full time in college and it's extremely tough to balance everything. Delegate as soon as you can afford to, anything others can do that doesn't take a lot of brains pay people to do.
5. Don't be afraid to scale, but do it slowly. My first purchase of over 10k was 6 months after I started, iirc.
(Several of these are probably specific to this kind of business, may not be generally applicable. Startups have a much different road where profitability isn't the most important at first.)
It took me a lot of time. Battling low self-esteem, giving it up for a while, following the wrong path, surviving after being fired for the first and only time.
I learned perseverance. Once I set my mind on it and worked around distractions, people and my own mind, I got what I truly wanted and I'm loving and learning every single day.
The course has an average rating of 4.62 and over 200 students. To date (since end of June), it has made $1182 for me.
This was quite a learning experience - aside from putting the course content together, I found out a lot about recording audio. I tried doing this in Thailand and quickly learnt that I was in a very noisy environment. First there were the echoes of the room itself which I fixed by cramming my microphone in the cupboard in-between blankets and pillows. Then there were the scooters, neighbours, air-conditioning, airplanes! This was a very frustrating experience.
If you ever make a course, make sure you have a nice, quiet recording environment!
I've also learnt that you can make a bit of money from having Udemy promote you, but if you want to make any decent money, you have to promote yourself.
I also believe from this experience that making one online course just isn't worth doing. If you're going to do it, you have to keep doing it. There is a learning curve at the start, and I believe the trick to being successful is to really work on promotion, and do up-sells to other relevant courses from your existing student base.
I learned a lot about managing an open source project, but probably the biggest thing was that I learned that even something as uncontentious as a Vim plugin can get a ton of hate online, including from Hacker News. I would hate to be working on a more contentious and visible project.
"I'm not dead" probably ranks highly. I am sometimes cast into a tournament against a patient, relentless salesman for death. The problem is, he knows everything about me. Everything. Every thought, every recollection, every secret shame, every regret. Everyone I've ever hurt, how I hurt them, how I let them down, how I failed them.
And he can, in a moment of pain, turn all of those into an impulse that I have to remind myself is just a feeling and even while I do that he's whispering "is it?".
Most of the time I am OK. But I know that I my emotions can just overwhelm me so suddenly and completely that it scares me. I am still learning how to live with me.
He'll probably make his sale in the end.
But I'm alive.
9+ months later, they are still sober.
Unfortunately, the friendship didn't survive. They really pushed my own boundaries, early on, but I hung in there, hoping and waiting per advice for their circumstances and perspective to settle down.
But, while they are no longer using substances, they are still, in my now more informed perspective, using people. Once they had other means of support, they didn't have time for me.
Still hope it all proves to be of benefit to their kids.
As for me, things I really needed to do, this year, nonetheless got placed on hold. This may even have contributed towards negative judgment towards me -- despite my circumstances making all the time I committed to them possible, in the first place.
Lesson learned: Take care of yourself, first. As also observed, ultimately, in the activity and choices of the person I was helping. They certainly took care of themselves -- sometimes at the expense of those around them who were willing to help.
Growing up, I had never had interest (or natural ability) playing sports. Like many here, I'd prefer tooling around on computers, reading, etc. Likely, this became a self-fulfilling prophesy about "not being a sports person".
Well last year, after some thinking of - "if not now, when? When I'm 40?" I went to a gym, bit the bullet, signed up, bought 10 hours of private lessons for squash (first racquetball, but I switched immediately after trying squash once). It is probably some of the most fun I've had in years, maybe decades. Met so many great people, actually feeling fantastic shape for thr first time in my life.
I'm 34, and am actually a "sports person" now. Laughing even saying it in my head. I've used this achievement/habit also to become more of a morning person (by deliberately scheduling games with people at 7 or 8am), and also to do different activities at the gym (e.g. high intensity interval training group classes; running, and even some weight-lifting). It's even propelled me to think more about the food I'm putting into my body, cook more, etc.
If you have never heard of squash, check it out. It's intense (1000+ kcal per hour), easy to learn, low risk of injury compared to other sports, and is often cited as one of the healthiest sports out there. It's tons of fun (even if you're terrible), has a nice long and rewarding learning curve, is very strategic (the chess-like aspect of it appeals to my technical brain), and again - just tons of fun.
A trusted technology friend passed on the advice to try it to me, so I'm passing it on to you all! Try some squashing!
But I had set out at the end of last year to write this tutorial. In starting a task that wasn't assigned to me by someone else, I could control and understand so much more about it: who the audience was, what its scope was, and what even was its point? I had enough of an understanding of the subject that I could grapple with and explain it. I was able to break it down and start to approach it as just...
I got into the habit of approaching it like I approached writing code: just a matter of structuring ideas and reflecting on whether they were understandable to people. At the end, I had a working running product that someone could read and follow and learn from.
I learned the hard way to stop focusing on liking everybody, and making better business decisions, especially regarding partners. I have a marketing background, and I knew that saying that code is easy, marketing is hard, but I didn't know how hard. However, it has been a blast!
Also, this december we open sourced and launched a pull to refresh library, which has been a great success!
I had a 26 student class. 9 studens got below a 90% on the final, I think 1 or 2 got below an 80.
I'm also going to stop being a TA this semester. I think I've been a big help to the students but I got offered a position to do real software development at the university. The pay is going to be crappy but it's ham-radio related so it'll be fun.
Teaching students let me actually teach myself better. I found that after breaking stuff down to explain it to my students I better understood it myself.
During this time of the year last year I was at a very stressful period at work changing to a new leadership role. I started working out more seriously, and signed up for a half-marathon, that I completed successfully (I had been running occasionally on my own, previously).
As the rewards of physical exercise were kind of immediate and didn't depend on external factors but myself it motivated me to put together a training schedule, and set the goal of finishing an ultra, inspired by some friends. I didn't communicate it to many people but just a few close friends. It was an endurance challenge, and I am very happy to have it accomplished.
Also, my performance review improved.
I the process I embraced the fact that I am much better at sales than at programming, I even learned to love to do cold canvas calling!
I accomplished this by building a unique iOS game that uses animated gifs for jigsaw puzzles. I wrote the app several times, and after giving it enough time, I was able to incorporate functional and generic programming concepts to reduce my code down to less than 1,000 lines.
I also ditched my resume because I didn't have substantial previous experience developing software (just 3 months) nor a degree of any sort. I just took videos of all my apps and put them up on a dead simple github pages site: https://danielhhooper.github.io
I interviewed and accepted an offer the following week.
They massacred it. I don't think anyone got past page 9. The feeling was worse than being told "Sorry, but I just don't love you in that way," after putting all your heart and soul on the line.
But the remorse lasted only an instant. I put that piece of refuse in a drawer for later re-working. Then immediately finished another longer pilot. Incorporating a very obvious yet fundamental change in attitude from "they just will never understand my genius" to "how can I effectively tell this story in the most economical yet artful way so that anyone can relate to it?" The response this time around was much more positive. "Awesome." "Would watch this." The spark had started a flame.
And so in just over four weeks I committed myself without reservation and finished my first full length feature (100pg). The result: through a small cohort of fellow writers I met via stage32 I will now be collaborating on a paid gig for a webseries that starts shooting soon!
What I learned: respect for the process and the craft. Telling a story well (and especially visually) is so much harder than it appears. Heed the advice of your elders and those with experience. And write. Every. Single. Day. Without excuses ;)
I'd wager a sizeable portion of HN possess the desire or idea for a screenplay. We need more accurate portrayals of the hacker ethos in media. As well as sci-fi with some actual science in it. So I highly recommend facing your fear of the blank page because if nothing else, the effort will make you a better writer, and perhaps a better person.
To get inspired start by reading great scripts:
The main takeaway for me was that, unless you can tap into a preexisting pool of demand, grabbing people's attention is as hard and effort-consuming, if not more so, than actually solving a problem. One-on-one, I always had an easy time convincing people I knew that the program is useful for them, but simply throwing it out there and hoping someone would notice it was unexpectedly fruitless.
This was very difficult for me. I love working, but I'd been doing startups for a little more than a decade, and startups require lots of attention. When I had my first child 2 years ago, I thought I could do both. I was wrong.
My family and I moved to the wife's home country where it is very cheap and I'm spending 6 months just being "dad." In my downtime, I'm working on some residual income side projects (I've already got one going that brings in $2k a month).
It's an inflection point in my life. Truly unknown future. When I go back to the workforce, what lies ahead?
PS - I also lost 8kg. :)
Using Postfix, Dovecot and PostgreSQL, you can read your mail securely via IMAPS on your phone and your desktop mail client. If your account gets hacked, you can just SSH into the server and reset your password yourself. No more getting locked out of your email account in an endless GMail password reset loop (https://productforums.google.com/forum/#!topic/gmail/HjW2Pj5...)
Recently eclipsed $100k in ARR as a solopreneur. Goal is $1 million in 2017 and to hire a full-time dev and a couple support staff.
My biggest lesson is that email marketing is the real deal.
I've done a lot of regular programming and some basic electronics, but never a project that involved getting a microcontroller to talk to a bunch of ICs. So, I learned a lot about how electronic components don't necessarily behave the way I expect them to. I also learned a lot about what can be done by using MIDI in ways it wasn't meant to be used.
I learned A LOT in the process, main one being that you should keep meticulous and separate records for anything that has the chance of being spun off. The company I sold grew out of my freelancing but was separate with a separate name. Unwiring the financials as well as the logins and everything else was a headache. It also looks better to your buyer if you can quickly produce accurate records on sales. I had to back-track and re-calculate several times, leading to more back-and-forth than was necessary.
Technically speaking I learned a few things, like Ray marching and distance field stuff, but nothing much I can point to and say "I did that."
I'm still here though, I made a few friends, I made and drunk some cider.
If I am on a good enough footing to make 2017 better, I'll take that.
- Understanding prolog/non determinism.
ps: I hope you all can enjoy prolog extreme beauty and concision one day if not the case already. It's not at all perfect but so tiny yet so grand.
Mine biggest accomplishment (probably of my life) was turning our almost bankrupted company into profit just in 4 short months .
I learned many great things, but the most important lesson is that if you treat your employees with respect and you don't hide things from them, they will stick around and help you to push through. Without them, I would have nothing today.
Growing up poor and growing into a lot of family responsibility made me think it was never going to happen for me, but I made it happen, and now I feel freer even in my day-to-day life.
Oddly enough, what I learned is that the type of shape I was in to run/walk a marathon slowly on back-to-back weekends (or even back-to-back days) was actually not all that great.
I switched my exercise focus to building up muscle mass, and getting faster at shorter running distances, and started running with some free running groups in Austin. Much faster now, and in much better shape. I was able to drop 55 pounds (210->155) and keep it off.
The app spread in the campus with word of mouth and gained 2000 monthly active users in the first two months. University found out and sent me a cease and desist letter and then later implement recaptcha on their online portal login form.
Thanks to this app I managed to get a decent paying job as an iOS developer. Kinda wild ride
Although it sounds like a burden, it actually freed me from a lot of stress. I broke out of the paycheck-to-paycheck cycle, allowing me to invest and even set up emergency funds that helped pay off an auto accident I got into.
Most importantly though, I've gained a lot of self-confidence. If I got fired or laid off today, the last thing I'd have to worry about is paying my bills because I'm prepared to handle this scenario. So I've started making more bold decisions at work like saying "no" to overtime or responsibilities I don't want to take on, which has further improved my quality of life.
I can't recommend budgeting enough.
I wanted to share the joy of learning, the joy of applying the learnings, the joy of building an own application. That's why I started to write about it (http://www.robinwieruch.de/the-soundcloud-client-in-react-re...).
I didn't expect the enormous positive feedback. I continued to share my learnings. Eventually I found myself in the position to teach a bit about React and its ecosystem on my website.
Finally I wrote an eBook: The Road to learn React (http://www.robinwieruch.de/the-road-to-learn-react/). Again the feedback of the community was overwhelming. In the end I very much hope that it helps people to get started in React like I did. At this moment I improve the material whenever I can.
Besides of programming, I learned a lot about writing and teaching itself during the process. Still I try to improve my skills by reading books like "On Writing Well" by William Zinsser.
To be honest, it's the first notable project that I've shipped.
I learned that I have a lot to learn, even if I'm comfortable with the stack. It's interesting balancing the migration between what we know right now and where we want to be. For instance, jQuery -> Vue -> SPA (?) + API.
We're also learning Docker, testing (frontend and backend, and CI / deployment. We've got a long ways to go, but I think if we're patient, we can figure out a solid foundation.
- Became an expert at node.js, postgres, react, and react-native
- One of my open source libs hit 1500+ monthly downloads on npm
- Built a product http://flowapp.fractaltech.in/
- Managed to score 2 customers for the product
- Developed basic understanding of machine-learning
(not to be confused with build tool with similar spelling)
The climbing experience was richer than I thought:
- Full trust and obey my guide, Alex is a great guide.
- Planning and equipment are the key for success.
- Presentation skills
- Great network of contacts
- Tons of knowledge
Launched my first webshop ( which is actually quite fun) in a niche ( 500 / month profits), which is nice.
Otherwhise, work overload made me quite agitated on the end of the year. But i'll get through it.
I learned a lot about developer communities and what makes 'em tick.
Personally, I became a homeowner. Some learning! But I don't want to spoil the fun for anybody.
What I've learnt is to avoid the hype and trust your gut. Don't go with the flow, the 99%, you'll get nowhere.
The content of that website is something very meta and I'm writing it since 2006. I thought only robots will read it. This makes me think secondary values are more important than the day job you do and think is the most important.
Since then I've taken up personal projects again (like a set of interactive economic model solvers for students), and really gotten to love the process of learning again.
I've also finally truly figured out what field I want to get in to, while it won't be easy to break in to quantitative in finance it at least gives me a direction to take my studies and an end goal of where I'm aiming to be soon.
This is a search engine for lectures; one of the great things is this is something my family can understand and use.
I've been really happy with the response so far (The Next Web & Lifehacker wrote nice articles about this)
I learned that it's difficult to sail across the pacific in a rowboat. Meaning, even though your startup aspirations may be wild, it's important to have the right timing and right team to move forwards -- going with blind energy leads to waste and burnout.
I learned that through hard and passionate work we managed to create something that seemed impossible to do in a country like Greece. Seems like it's not.
Now with a March 16th launch date we will be launching on ISS.
I'm still alive and I think this year I would have made $1,000.00 at most as a freelance web developer. I should add I was working full time as a factory worker for a bit(for the most part till I became unemployed again).
I was working at a factory. Maybe if I'm lucky I get hired at a tech position.
I never was able to finish anything. With Curie it's also an important one for me, and probably because of that I was so determinated do finish it. One of the biggest reasons was that I knew that the product could help other prevent having the same back problems as I had.
I worked on Curie with 3 other co-founders for nearly 1,5 years now after hours, but we never had the energy or time to get it done. Because I was feeling that my teammates didn't put so much effort in it I finally decided after a couple of month trying to motivate them to let them go. As you can imagine it was really hard to do that, and I felt in a kind of depression about that I knew I needed to be make Curie happen.
Now it's in open beta and soon we'll be launching a chrome extension.
It has been an interesting journey grappling with creating a responsive, embeddable, interactive JS player on front-end while dealing with the idiosyncracies of iCal and Google calendar synch on the backend.
I learned how to work well with a distributed remote team and get a product released.
Things I learned:
Be extremely careful with your demo apps, people will see the demo work and think its most of the way there and just needs polish where reality is very different.
Grasping new technology stacks is harder for many people than I anticipated. I chose Erlang/Elixir/BEAM and I wouldn't change that, but onboarding has been a challenge. What I see as mostly syntax and just learning what philosophies work best on a new VM others see as a sea change that takes much longer than anticipated to understand.
I started to keep a paper journal this year. Maybe that is my greatest accomplishment?
I always loved learning and teaching, and a side effect of this is that now I've regained the curiosity I always had about the fundamentals of our industry (I've a CS PhD). So now I'm back reading about the fundamentals of electricity and building 8-bit digital adders with basic AND/OR/XOR logic gates .
There's still lots of fundamental things that I want to re-learn, and for 2017 I'm thinking on writing a book about learning programming from exercises (with just enough theoretical concepts) starting from flow-charts and pseudocode, up-to some basic algorithms / abstract data structures/types (probably using Python). My idea is that there are lots of students out there that could benefit of learning how to program by solving focused exercises and learn enough about algorithms and structures to feel capable of doing more complex things (i.e, not feel the "impostor" syndrome).
 - https://www.amazon.com/Code-Language-Computer-Hardware-Softw...
Learned mostly in the areas of mechanical engineering, robotics, manufacturing, materials science, product design, Solidworks. Refreshed electronics knowledge.
Oh yeah, and quit smoking a couple of times ;)
It was a real culmination of what I've leart over the last few years and it was satisfying to actually produce and ship a finished product. I also leart A LOT about the world of art during the process which has been amazing. The feedback I've had from users has made it all worth it.
What did I learn? You would not believe what people commit to their source control. Gigabyte text files, millions of files in a single directory, files with the immutable bit set etc... Some of the most bizarre things I would have never encountered.
My defensive programming skills when file processing have improved greatly as a result.
Sure, it was small, and far from the biggest thing I've written, but it was really and legitimately useful, and actually helped me with a real problem that I had. Most of my code is just oddball projects and weird experiments. It felt good to make something and see the effect right away.
It taught me that in the future I'd need to make my projects more immidiately applicable to Real Life. It makes them more interesting, even if the actual code is fairly banal.
2016 was another miserable year filled with 24/7 intrusive/harassing/distressing thoughts and physical pain/discomfort that left me unable to do anything but sit around being harassed.
I'll be 31 soon, and thus far have spent the last 6+ years sitting around in this state unable to do anything, work, think, etc.
Others say it's some sort of mental illness, but I say I'm a Targeted Individual (ie, someone did/is-doing this to me).
Also, I learned conversational Swedish and traveled to Stockholm twice. Fun times!
Gaining visibility even in a relatively small market like Mac apps is a huge effort and nobody cares about you and your product on its own.
2. Yesterday I've finally managed to restart my blog.
3. I've learnt my little kid couple nice stuff.
4. Despite the fact I was overworked in December and started to work on side projects mentioned above, I've managed to spend more time with my family.
Looking forward what next year will look like :)
Now I don't know what to do, it's so hard to find a job in this country. I'm taking MOOCs about data science and python because there are so many job listings for such positions but who will hire a forensic anthropologist? I was lucky enough to get into this job and now there's nothing for me in the horizon.
It is an incredibly deep and rich discipline which invites me to multi-dimensional mastery: kinesthetic, emotional, sexuality/boundaries, musicality, finding place in a complex multilayered society and communities, relationship to learning/failure/frustration, intimacy, discipline... and more. It is incredibly beautiful and complex, difficult and rewarding.
Mastery with infinite possibilities and thus no ceiling. No graduation :)
I'm fortunate to have found a school that approaches it in a profoundly deep and felt way, and has redefined teaching in the process.
I feel extremely grateful. It's changed my attitude toward leadership, relationships, music and community. What a gift.
Then proceeded to work on and push through any pending changes that allowed us to pass three separate audits.
Towards end of the year, finally hosted the first meetup at our office.
As to what I learned:
1) Implicit couplings are incredibly easy to introduce, even with designs that were explicitly set to avoid them.
2) Auditors mean well but rarely have a wider technical background. In gambling industry they are also terrified of running production systems in the cloud. Architectural decisions must be paired with what amounts to a PR effort aimed at third parties.
3) Organising even a casual event is a lot of invisible work.
I wrote the backend in Rust, so I was able to learn quite a bit more about Rust in the process.
Since Trump won the election, I'll devote some time in Q1 2017 to improving the voice quality. I'm especially interested in applying deep learning techniques to generating a larger n-phone data set.
My second largest accomplishment will be what I'm going to pull off for New Year's, but that's a surprise. It involves multiple watts of lasers, though. :)
I put two PhD applications in to top departments.
I got married.
In the process I mostly learned the same lesson from my MSc: research is mostly a lot of background knowledge to acquire and legwork to do, but if you've done it right, you can address a big, difficult question by wearing it down until it's small enough to work with.
It's nothing special and there's not a lot of content, but I hope to learn a lot and make more connections as the editor.
I definitely learned to share my accountability with other people. I had enough to launch in Feb of this year but I didn't launch until December when there started to be external pressure.
Additionally, I learned that for things outside of typical teamwork, it's necessary to put hard deadlines on things. When someone signs up to write a blog post I can't expect them to work on it in preference to sprint work unless there's a deadline or incentive.
I licenced software I made to my current employer and turned that into a mini-SaaS business.
I negotiated my own job role in a specialised area but turned it down in favour of moving countries with my girlfriend.
I gave a TEDx talk on legal technology.
2016 has been a rough year globally but a pretty good one personally. Whilst it has had its challenges, overall I've learned to take more risks and to say no to more people.
Next year, I want to create more SaaS businesses - though right now I've got a bit of creative block around it.
Now changing them is a whole 'nother story and I still am looking for answers on that.
I've being constantly working on my personal projects and reading lots o technical books.
The down side was that I hardly had any holidays in 2016 and was consistently clocking 12 hour work days. So exhausted to the core as well.
For the curious, we are working on http://www.reportdash.com
Also finished my Masters and got a remote job at an awesome startup. Learnt to be less afraid of failure - better to apply to as many universities/jobs as practical and then accept the best offer. Wish I realized this a few years back.
It's the very first app to ever launch as part of a musical and yes I realize how ridiculously "Silicon Valley" this is :-)
I participated in my first boxing tournament last month and won the bronze medal. I think this was my greatest achievement of 2016.
It wasn't such a big tournament as it only had 15-16 boxers in my weight category and I only had 3 fights.
I was really scared before getting into the ring for the first time, but completing three rounds of my first match was a rewarding experience.
Here's a screenshot of the Squash button in action: http://bit-booster.com/bb/squash.png
I'm looking to improve the security of potentially ~82% of websites in early 2017.
Learning: Was in product development first time. Scrum is tiring in nature but good when used for rapid development. React-Redux-TypeScript is a great combo. Still not sure on using inline styles for react components
Haven't looked back since; I'm happier, less stressed, earning more and I've had more holidays this past year than I ever have done in a single year.
I think what I learned was, don't spend seven years on the next project :- )
* sold side project
* started another side project and with more users than all previous projects together
Want to now build a VR robot for telepresence.
Climbing helped a lot with this. In the process of getting more fit, I realized more what I want in life.
You can look at the source of Bootstrap to see how they accomplished certain things if you'd like, but if you're doing anything more than prototyping (and even then), I feel there is very little benefit to using Bootstrap these days.
Once I was told to ignore Bootstrap and just create my css myself (using Sass or CSS Modules) I find I'm making the same recommendations to others. It doesn't take long and you'll have a much better idea of what is happening on your page.
Your html and css should end up being much smaller as well.
I've been using Bootstrap 4, since it's already stable and will come out in a few months anyway, so I won't have to upgrade anytime soon.
If you use libraries that depend on Bootstrap, you might want to check compatibility. I was using Bootswatch and the developer didn't upgrade the code to Bootstrap 4 until a few weeks ago. Other than that, I see no reason not to use the latest version.
I'm surprised by all the comments saying that you don't have to learn Bootstrap but you can just look up the components every time you need to use them, suggesting you use Skeleton, or that if you use Bootstrap you don't want to learn/know CSS. Nonsense.
I've been using the version 1, 2 and 3 and I've never felt like I needed to learn it. Usually I just open the doc when I need to use something.
Regarding learning BS3 or BS4, I'd opt for BS4. All you have to know what things BS4 provide and use them appropriately. Not to mention, some fairly good CSS knowledge is also a pre-requisite. One of the themes we recently used is startUI (google for it). It's on BS4 and the components were easy to integrate in apps.
You said "learning", so I'd still suggest learning the actual CSS. Of course, when you become a bit comfortable with it, you'd have already learned Bootstrap.
Here is how I'd for;
- Use Bootstrap 4 or even 3 to learn your CSS. Use it, go through the source codes and learn from there.- Keep doing CSS (feel free to try other frameworks too) and you should be on your way.
So, take it easy on yourself, start with something you can start off (and produce something you're proud of) and begin learning real CSS in the process.
Well, my team specialize mostly in fixing projects shoved down by developers using Bootstrap, where the enterprises needed to go to market quickly. Once they reach critical bloat-stage, we go in to clean-up, make the sites 10-30 times faster by removing all of Bootstrap and other frameworks and staying really lean (use a minimal framework or a very low footprint one.) We, sometimes, end up developing the "Bootstraps" for these companies.
But if you're just trying to bang out a small project quickly and have it look nice without needing to muck with CSS too much, then a framework can be very useful. These days I prefer Semantic UI over Bootstrap:
Now, learning bootstrap is not too bad. All you need to donis figure out how it defines the layout grid, how it handles margins, padding, and gutters, and how to use different classes to make the site responsive. Should take a couple of days. Ping me if you need help. :)
However, I would recommend to move away from Bootstrap to Material design for example, I feel (after using both) Material design is more well though framework and it also has bindings with Angular (that is if you are building angular apps) through [angular-material](https://material.angularjs.org/latest/). There is also standalone framework [getmdl.io](https://getmdl.io/started)
Then there is a very detail documentation on how to think like [Material design](https://material.google.com/) way by Google . Checkout the components section from the menu, it is really nice they way explain the theory behind why each component the way it is
If you are trying to roll out some new software for a startup or project and you want it to look good and semi unique then I recommend just buying a theme with all the necessary components (dashboard, graphs, whatever) you need. Themes are pretty cheap these days. Usually one of these themes has picked some sort of "foundation" library and you can then learn that.
Basically force yourself to pick by necessity and not what the "future" should be...
Personally, I would be hesitant to go with v4 because of losing support for older IE browsers HOWEVER v4 is built on flexbox, so it should in theory be a little bit more of a sane implementation.
I would do some more research on what are the differences, it seems like with v4, they are making the API a little bit more simpler, but I haven't dived into it yet.
All these frameworks are just COPY & PASTE the pre-made code. For example, you wanna button in that style:http://v4-alpha.getbootstrap.com/components/buttons/
Copy that code and paste into your HTML. Whatever v3 or v4 are the same way.
If your learning way is memorizing the code without checking the document each time, then I'd say v3.
I say this because I personally have dived head first into using a CSS framework without first fully understanding a few key CSS fundamentals. This made front-end work very hacky and involved a lot of trial and error.
Further along the line I've also been burned once or twice by adopting a CSS framework, only to have breaking changes from future updates.
So really it depends on your situation, whatever it may be.
I happen to like Semantic UI a lot, but you can also consider something smaller and less proscriptive than Bootstrap, like Skeleton or UIkit.
If your question was should I use 3 or 4, then my answer would be, depends on your project.
But for learning, the version doesn't make much of a difference as the general principles are the same.
This is doubly true if you don't know CSS in the first place.
i.e. you will have to learn the new thing at some time in the future so may as well not incur that debt and go straight to the future.
You can always switch to BS4. BS3 is not something that's getting obsolete.
I think it would be better to just have a simpler GUI for a VCS that looks andfeels more like an email client. Commits would show up as a list likeemail summaries and opening them up would maybe show the full diff. Brancheswould show up as a an email thread/conversation. Maybe extra logging detailslike "so and so has seen your commit" or "person A resolved a conflict here'sthe conflict state and how they merged it". Files involved in the commitwould look like they are attachments and "downloading" the attachment would reallyjust open the file at that commit. ...Searching for stuff is probably importantto your workflow?
...I'm not the target market, but I get it. I hate email based workflows, and I could send a couple of email critiques too ;)
I think this would work best with those working on smaller projects with maybe oneor two other collaborators that do not make changes at the same time. I makechanges, other person looks at the changes, maybe makes some corrections andsends it back. Maybe there are some people that just want to be notifiedof updates. I want to say that your target user's primary responsibility isn'tprogramming. Maybe a designer, sysadmin, or researcher? ...Someone who writesa few scripts here or there.
How would rebases work? Cherry-picking? Reverts?
Email clients were build to send emails not to be VCS repos. It seems like you would be bending an existing tool to do a job that is already handled by specialized tool.
Then, you set yourself to write for Windows and Ubuntu only. You're forgettingall the rest of the Linux users (it's quite easy to write something that willonly run on Ubuntu and not on Debian), BSD users, and OSX users. This isa very bad attitude.
Next, I can't see how this is supposed to work or fit a programmer's workflow,but it may be just me. I don't see how it would operate with an e-mail client(or maybe it's supposed to be an e-mail client itself?)
> Configuration shouldn't be much more complicated than setting up an email client.
Setting up an e-mail client is a quite complicated thing. Setting up a gitrepository is quite easy, on the other hand. I don't see how this is win.
I've found that the issue with being a remote employee is the employee part. My experience has been that trusting your job security to an employer is just not as safe as it used to be. Nowadays as a freelancer who works on mostly long-term contracts, it's possible that some of my clients wouldn't think much of replacing me, but if they do decide to stop using me, I can grab another contract. My office doesn't change. My machine is still my machine, i.e. they're often the more replaceable one.
However, and as others point out here, this only works if you have lots of experience in something highly in demand.
My experience is that remote work is the exception, not the norm. The only way to get stability as a remote employee is to have an exclusive skill or some other advantage over the other employees, eg. "I'm the only remote employee, but I'm the only one who is a proven data science whiz," "The company cannot find enough locals who know Scala," etc. And even then, your stability is still contingent on this supply/demand imbalance.
If you do those three things well, then you are no more disposable then any other employee.
There is something human about being able to see the person who is doing some work for you.To be able to say hello without agenda. Ask how it's going.
Yes you can do it with Slack and Skype but nothing beats walking over to someone.
In large companies, working remote made me feel disposable. Small companies, if you can get stuff done, you feel valuable while being autonomous.
"The ePrivacy directive more specifically Article 5(3) requires prior informed consent for storage or for access to information stored on a user's terminal equipment. In other words, you must ask users if they agree to most cookies and similar technologies (e.g. web beacons, Flash cookies, etc.) before the site starts to use them."
Well established and known consultants may occasionally get work solely off their internet presence. But mostly their websites support their other marketing channels: their websites provide more information to potential clients that have heard of the consultant by other means (not via Google SEO'd search).
Control matters (what if I need to make a change to fit a certain scenario? How does that happen? Is it propagated upstream? How/when?)
Searchability matters. How do I know what I am looking for, especially across domains and companies?
Anything that is generic, e.g. a double entry accounting system, an Actor model, etc. should be in a package management system - a Gem, a Nuget Package, a NPM pacakage etc. rather than copy pasted.
At the micro level for specific line-of-code level problems (usually due to language/platform quirks) we have StackOverflow.
How do I specify what I'm looking for? What level of granularity does it work at? What languages does it cover? How is this different from using libraries? How can I trust the code I find?
Does it exist yet?
second, even code is found, building requires lots of work. missing dependency, mismatching interfaces, unsupported os...
99% of programs/apps already exist.
99% of things I say and do have already been said and done before.
Code reuse is not the solution. We must rethink software and communication as a whole. As far as I know, nobody is attempting anything close to this.
PMs are welcome.
I almost lost hope on my last job jump when it took me three months and six on-site interviews before I got an offer.
What will help you the most in the search is probably not what you think. I thought have a GitHub and some cool projects and a nice blog would make landing a job easy for me... Annnddd 95% of the companies I talked to didn't care.
What helped enormously was studying the same questions that interviewers are likely to pull from. Once I studied hard on interview Q&A I went from no offers to getting three in the same week.
The interview process is usually borderline hazing and the questions being asked have little or no bearing on the actual job. The job requirements listed are actually just some staff engineers wish list of what he would use if he could rewrite the garbage fire that is the application you'll be working on.
It doesn't help that half the time the manager interviewing you hasn't written a line of code for ten years... or ever in the case that you're interviewing with HR.
My theory is that male dominated fields tend to be steeped in competition, or at least the goal is to appear that way. You don't want your hiring to be "weak" and new guys definitely need to "climb the ladder". This makes interviewing for these positions a complete nightmare.
Just keep up applying and remember the interviews are tough on purpose. HR doesn't look good unless they can bring in an endless stream of top tier applicants. Management doesn't look good if they hire "anyone that walks through the door". The result: companies throw away many, maybe most of their good applicants.
The industry is crying out for developers, theres no reason why you wouldn't be able to get a job. Yeah the industry is fast moving but businesses aren't. If they choose to use a framework, them its going to be in their legacy code base for a good few years.
Remember,you are not paid to develop, you are paid to make the business money. Would you rather hire a developer who wrote an amazing 200 LoC a day and earned you 10k or the developer who deleted 3 lines, sent a few emails and earned you 100k?
Apply for every interview, don't aim too high - you can get a junior position no problem.
I think it's a good idea to choose a niche, and stick to it. Full-stack devs are awesome, but there's nothing wrong in sticking to a particular competency. Looking at your profile, it seems you're pretty good at writing Swift/Obj-C apps. If that really interests you, why not stick to mobile as a domain? I feel it's easier to keep track of how the ecosystem changes, in one field.
As for jobs. I'm not entirely sure what the problem here is, but I know what it's like to not have the right qualifications. I studied engineering for two years, dropped out because the coursework had zero coding, studied Russian for 6 months and then dropped out again due to campus politics. But I've managed to hold jobs with IBM, Cvent and some media houses simply because I could convince the overlords that the lack of a professional degree didn't stop me from executing what was expected. But it was hard. Have you tried checking out spaces/events where startups converge, and probably pitch your skills to them? A good place to start would be coworking spaces. Establish a relationship with the space's owners/managers, and they'll happily introduce you to teams who need your expertise. Many startups don't care what certificates you've got, so long as you add value. And if there's a startup that does look for a degree - well, you probably don't want to join them anyway.
I hope this helps. Please don't give up - obviously you love writing code, and there's no reason why circumstances should make you give up doing something you love. :)
Pick one set of tools to be your current 'major', say Swift perhaps and spend time getting better at Swift than the rest of the stuff you know. Apply for Swift jobs and be confident!
One more thing. Always be prepared to switch your major to a new one (language, platform). If you ask me, Elixir/Phoenix has lots of potential and 2017 might be seeing a lot of job openings for it.
This takes a lot of pressure of since quality is not has strict in the Chinese market, and there is not that many people who have 10+ years experience in CS things. So if you show up with a "let-get-shit-done" attitude, or just a sense of quality, you will be well rewarded.
You can also work on scales that are normally only something for the best and brightest in SF etc. Making day to day task be more challenging and fun.
On the social side, its fun to be an expat, everyone and their grandmother wants to ask you questions and you get a extended family with other expats in no time. The social pressure from home goes away and you hang out with people from all walks of life, on the other side of the world we are all just guests.
China worked great for me, but there is other new crazy markets like Vietnam, Indonesia, Burma. Where a middle class are starting to use their smartphones more and more.All these countries needs localized versions of basic apps, or as in the case of China, niche version of basic apps.
I remember when I was stuck in traffic on the highway back home from work, before China, and thinking if this is it. A change of scenery was all I needed.If you do what you love and it still doesn't feel right, my bet is that you are in the wrong place.
Apply to 200 software positions, might be good to start with internships. Every company you can think of, big and small.
Every interview you get, ask the interviewer what they thought of your answer or if there was a better way to solve the problem.
Write down every question you get asked. Google them later to learn the better answers you don't know. After a while you'll know the answer to 90% of the questions most companies ask.
Also sounds like there may be an attitude problem. If you've never had a software development job then how can you be so confident that you can get the job done? That's plain arrogance.
Approach the situation with a growth mindset - you have loads to learn and you can't wait to absorb it all from your peers. This is a lot more encouraging than someone who thinks they know it all.
And if after all this you still can't land a gig, do work for free just to get something on your resume, to get considered at the decent/great places.
You won't get your ideal job tomorrow but through hard work and dedication you can get there in a few years no problem.
Message me and let's talk further. We're always looking for strong SWE applicants. Happy holidays and remember to never give up! <3 for code. 'Tis the season to help others.
Also - coding skills alone are not that hot - they just make you into a replaceable cog. However, if you combine this with domain specialization this could make you into a valuable contributor. And by domain specialization I mean what ever is the core business of a business. Tomato delivery logistics? Insurance policy business rules? Trash truck maintenance database operation? (I'm making this up, but most businesses are run by their own rules and terminology - being familiar how they work gives you the right to claim 'domain knowledge').
I'm 100% sure there is a domain for you to specialize out there. You'll find it if you don't give up. Social skills are probably a really good asset here. Stop talking to HR. Start talking to the upper management directly. Everybody likes to interact with a nice person when they have the time - unless they are lizard people, in which instance they should be avoided in any case.
In my experience a software development job is often the easiest way to destroy what you may love about programming. There may be exceptions, but many of the jobs and their limitations cannot compete with coding out of passion. Jobs in the software development industry are not the only way to make use of and grow your programming skills.
You seem overly concerned about this. If a company wants to prevent themselves from hiring someone perfectly capable of doing the job (namely you), then they're probably foolish and you don't want to work there anyways.
On the other hand, it's possible you're mentally hung up on having a desired skill set that's seemingly forever out of reach. If that's the case, just resign yourself to the fact that software development requires perpetual learning in a field where the ground is always shifting beneath you.
Keep in mind that a typical senior developer is just someone who has enough experience to know how to learn fast and not fall victim to common pitfalls in the process.
I suggest finding a job at a nice place to work where you'll be doing something that you enjoy, then worry about the technology stack later. Good companies usually understand that both whiteboard-style interviews and formal degree requirements are bad. The best ones explicitly state that they don't care if you're inexperienced with their stack, so long as you have solid experience.
>I really feel like giving up.
If that means starting a company as some of the other comments suggest, don't. You're 24. Enjoy your youth while it lasts, don't piss it away doing a startup.
A cursory look at the everyday applications that companies get would make you realise how you are far ahead of the curve. I would advice you to not get intimated by job requirements and start applying. If they don't reply, try following up (don't worry you are not intruding). Try reaching out to your network if anyone is up for hiring. Get comfortable doing interviews and meeting people. And don't get discouraged by rejections. Companies, after all, are run by people who have their own biases and idiosyncrasies. They might pick up the wrong impression or you might get rejected for a reason that is far disconnected from your coding ability.
Lots of good advice already given out here. But I would like to add some of my own view points
About me : 23, ex-WalmartLabs, currently working on my own startup.
There are many ways to become a software developer, it all depends on what kind of role you're aiming for.
- Software Developer (SDE)
Typically the job offered to most young grads at the bigs cos (google/linkedin/walmart etc). They want to test your algorithm and programming skills. Check out , ,  . It should take you 1-2 months to go over most of this stuff and several more to get really good. Start applying once you have a grasp of the basic principles, perfection only comes with practice.
If you're serious about such roles, I recommend spending at least 3-4 hours a day doing these problems.
- Technology specialist roles (IOS/Android/Node/Python/PHP etc)
These also require some programming knowledge. Use the above resources and at least do the basic Data Structure questions. Apart from that, showcase your projects, contribute to other libraries and/or roll out your own.
Another cool field to get into. I am not well versed with the requirements myself but AFAIK, you need lesser DS and algo skills here and more tech domain knowledge.
Just keep doing what you're doing right now. Find some consulting firm to market your skills for you. The monthly HN thread might be a good way to find leads/contacts. Can also consider bidding for projects on upwork/freelancer/others.
All in all, only thing I can say is that there's no need to be disappointed. You will get a job. You just need to prepare with a proper plan.
0 - https://www.geeksforgeeks.org (Recommended at least basic linked list, trees, arrays, graphs and greedy algo questions)
1 - http://www.leetcode.com (Do all these questions)
2 - http://www.spoj.com (can also use topcoder for this. Use this to level up your skills and land the high paying jobs )
Shortly thereafter, I rediscovered programming and I've been doing it ever since (20+ years). In hindsight, I think I had just gone through my first bout of burnout. I still find electronics interesting and enjoyable. So burnout may be one aspect of what you're experiencing.
Since you're an extrovert, you have a natural propensity that many people don't have in this industry. That can be a superpower for you. You might excel at giving talks, communicating with other teams, managing groups, and the like. The fact that you enjoy development and have put in the time means that these activities won't be vacuous.
The feelings of exasperation that you have are similar to what many others--novices and veterans alike--are feeling. Things change quickly in this field. Many others have written about how to cope with this. It's a real thing but something that can be mitigated and gotten past.
You might consider taking a step back and recharging. The New Year time frame is an excellent time to do so (generally speaking). Think about a few goals that you may want to focus on this year. If you pick a project, choose one that means something to you. It could be one of your own or someone else's. We live in an amazing time of open source and collaboration.
The main thing is, don't worry. You've got plenty of time ahead of you to pick your path and make things work. The fact that you're reaching out and searching for answers is a great indicator of future success. Just keep moving forward.
Sometimes you get overwhelmed by looking at other people's success. Sometimes, I feel like giving up too. I feel worthless looking at some people who have achieved a lot before they turned 30. But I've got back up each time I was depressed. Never give up and don't stop looking. Keep building stuff and learn new things. Good things happen to people who keep trying even after failing hard. All the best.
You mention experience with Java - Maybe going the J2EE route could open some opportunities.
Some may say going down the more traditional enterprise stack is boring but I do wonder if that's where there is more work locally as opposed to work being sent offshore to a low cost dev shop that works with web /php / etc.
Of course I may well be wrong, but it's one perspective.
The point is in the EU most of the unis are really just not that up to date when it comes to teaching you the real deal ( minus math and cs basics). And they are inflexible bureaucrats.
Doesn't move as fast as you think. Tons of work doing "boring" work. Read what Scott Hanselman says about "Dark Matter" developers: http://www.hanselman.com/blog/DarkMatterDevelopersTheUnseen9...
Makes sense ?
PS: If I had to pick a focus area I'd do AI. Supply and demand are in your favor.
Starting to grow my own vegetables aswell so I dont need cash so much anymore.
1. You can do this and you are not alone! I look good enough on paper that I get a seemingly endless number of job leads. And I still cant make it through the hiring pipelines at seemingly anywhere. I know people way better than me that cant either. The creator of homebrew? Max Howell? Yep, that guy. He couldn't make it through the hiring pipeline at Google. https://news.ycombinator.com/item?id=9695102 It isn't you, remind yourself that it is not you. Just keep going forward. You will get there. You will make it.
2. But is going to hurt. The hiring pipeline in this industry is broken, completely utterly broken. It will not be fun.
Until you make it, it will be rough. It is just the way it is. There wont be any saving grace or magical advice that will make it all better. It will be rough, it is that simple. Most people outside of the right stereotypes and demographics wont make it. If you don't fit the right demographic you will have to work 3x as hard and suffer 3x the stress and anxiety as others. But the good news is it can be done. You can do it.
First step; figure out what your weakness is and begin to work on it. You can pinpoint this by figuring out where in the pipeline you are continually failing.
Then work at getting a job the same way you worked at learning to program. Getting a job is a skill, don't let anyone or yourself convince you that just because you can code a job will happen. They don't just fall into your lap. You must tackle getting a job with the same motivation, and dedication to self-improvement that you have when learning a new framework or programming language.
If you cant get your foot in the door at companies, if you cant get them to respond to you, then your problem is you look crap on paper. Go and find people that look good on paper, look up the thought leaders, the people whose work you see constantly. Then copy what they are doing. Make open source projects, contribute to their projects, write articles. Eventually you will look good and the leads will start flowing in.
Now here is where it gets harder. If you are failing screens, you haven't learned to talk right. Practice learning how to talk about your work and answering questions (and asking them). Start asking after the screens for feedback. You will eventually learn what you are doing wrong and then you can work at getting better at it.
If you are failing the whiteboard challenge phase of hiring, then get good at them. Go to HackerRank and solve solve solve until things get easier. Recognize that they are puzzles, they are not programming. There is no shame you suck at them, you aren't trained as a puzzle solver, you trained as a programmer. But you have to practice the skills they are testing, and they will be testing you to see how fast you can reverse a singly linked list. Recognize it is silly and stupid, but get good at it anyway.
What helped me: talk to everybody that you are looking for a job. At every party there might be someone who knows someone that needs someone.
Coworking spaces are not for everyone and it depends on many factors, specifically your personality type and your ultimate goal for a space. ie: if you ultimately want a space that helps you extend your network and youre willing to sacrifice the fact that the environment will be more distracting than working at home, youll more likely forgive the latter to gain the former.
Whenever I need privacy, I can put in my headphones. The only down side is when I need to make a phone/video call.
I have a pretty nice setup at home, quiet, a few different setups to work from so I still get more work completed at home vs. co-working or coffee shop.
It is nice to get out every once in a while but it's not something I would do every day or even a few times per week. So If I want to get out I go out to a coffee shop.
Now if I didn't have a private area to work from at home I would definitely consider using a co-working space.
I prefer much much more coworking spaces, the more crowded the better for my focus. Ironically is deep silence the thing that disturb me the most.
However - it's great for networking if you participate in a well-organized one!
I get lazy at home easily, I turn to lay down and just pass out sleeping.
3.) "Services that others developers build upon" do not exclude the front-end. D3 is something other developers build upon, along with front-end interfaces to back-end services. There are many more examples of this.
Anyway, to answer your question: it is yes. Large tech companies readily employee developers to work primarily on the back-end. To increase the likelihood that you'd be working on distributed systems, I'd try to join a team that works on a product that is already at scale (Google Maps, Facebook Newsfeed, Amazon AWS, etc.)
But yes, that's a role companies hire for all the time. I believe we are currently hiring for those roles as well.