You can also use http://lmgtfy.com/?q=sicp for a deeper understanding of interpreted languages and language structure.
It strikes me as similar to how .NET is cross platform. Command line apps will run, but anything with a GUI would have to be written with a cross-platform UI kit.
Companies do not pay you by value, generally speaking. Rare ones do, but most often you are paid whatever they can get away with.
That is why you are paid close to your junior colleague. Everyone has base living expenses that drive much of salary demand. Anyone without a job will undercut you towards that level.
But if you look at it another way, your pay is not much higher, but your savings rate is, after all your expenses subtracted.
Maybe he had a better sense of what he was worth, or what the company was ready to pay for his skills.
Ask for more money and that's it.
I would stick to doing whatever will give you the most confidence when talking to companies. If that is studying data structures/algorithms then keep doing that. If its launching a side project focus on that instead.
Beyond interview prep, consider that your job search is similar to a sales process. A couple of books worth reading as you think through your approach to the market...
Gitomer's Little Red Book > http://www.goodreads.com/book/show/75890.Little_Red_Book_of_...
Perry's Guerilla Job Search> http://www.goodreads.com/book/show/9746430-guerrilla-marketi...
Best of luck!
PS. If you need an test interview email me. I'll try and help.
You shouldn't. If you have a github account with a couple repos that are not forks you're good.
Also, I don't think reading books on interviewing and solving interview problems is a good preparation. If the company doesn't focus on what you have done (like your own projects, which sound great) and instead gives you stupid interview problems on the whiteboard, run away.
- Don't ask things you can easily find yourself. I've had junior engineers asking me "does git blah has a flag for ...?". It's disrespectful of that person's time.
- Don't question every tiny little thing you come across. Organisations can't maintain perfection, there's gonna be ugly things and people are aware that there's always room for improvement. Sometimes there is complicated history behind things that look stupid on the surface. Some things are the way they are just because they are. Not everything has some grand reason or justification behind it. Sometimes people keep asking questions like "Why was this written this way? Why was it not written that way? Why can't we make it better? Why can't we make it faster?"
- Remember the ugly crap you are seeing today was someone else's shiny shit some time ago and you are not an exception. The cycle will continue and the perfect little happy function you are writing today that's gonna solve everyone's problems is going to be the next person's ugly crap to rewrite and refactor and clean up after you have moved on.
Companies, divisions and teams are inherently social and political. Communication is very important. Understanding other people's perspectives, even if you disagree. Keep your emotions in check. Take the high road. Don't assume malice when incompetence is a sufficient explanation. Go out of your way to help other people. It builds good karma that will pay you back. Get to know other people in the company. Talk to them and show interest in them.
Perception is king. The only thing that matters is other people's perception of your you and your work. That said, the best way to increase people's perception you is to be a hard worker. Manage the visibility of what you're working on and look for visible things to do. When a department is being downsized, it's the people who are perceived to be of high value that are retained. Remember that you're being watched, even when you think you aren't. Don't look at porn at work. Don't be the last to arrive at work or the first to leave.
Knowledge should be your main goal at this point. Knowledge increases your value. Learn new technologies. Absorb as much as you can. Become the expert in niche technologies used by your team/company. It is your responsibility to make sure you understand what needs to be done. Don't expect someone to explain it to you. Make an educated guess about what are the relevant for next year and learn those. Code at home. Follow your interests.
Rule #1: Never ever stop tinkering or hacking on your own interests.
Rule #2: The passion to code will come and go, but keep your mind and body razor sharp with quality food/exercise/sleep.
Don't try to reinvent the wheel. Every problem you're trying to solve has probably already been solved.
Verify all of your assumptions - ask questions, and realize the context the answer was given (i.e. the same answer may literally not apply to production vs development enviros or one language/API vs another).
Learn how to debug (this is an art), write tests, formal and informal QA procedures, write documentation, and how to get your code pushed upstream (the process) without breaking the system or anyone else's code.
Even if you've mastered the problem domain, most teams limit the ability to contribute too much the first couple of weeks because you need to earn the trust of your team (usually via a combo of defect-free code, humor, and general geek knowledge). Once trust/confidence in your ability is established, you will have plenty to do, and lots of guidance if necessary. But you may not be able to implement your idea for a new foo() in the product until you have reached that point. But watch out for NIH syndrome too.
Rely on more experienced members to help you organize your code files and assets to begin with - align with whatever the team expects. There are project standards, naming conventions, etc. and most of the time it's not written down. Or self-conflicting / clear as mud.
Don't be the dev that delivers sub-sub-standard code that's full of bugs. It's OK if it happens at first, but understand why it happened (root cause analysis?)
If you get stuck, please ask for help (or pseudo code) sooner rather than later. Like an hour or less. Some team members will be better teachers than others.
Good luck and happy coding.
 Consult experienced wheel builders first to make sure that it's your ONLY option.
This is in contrast with senior engineers, which are expected to be able to handle responsibility for a large system or subsystem, and to be able to design and coordinate execution of work at a larger scope.
In consequence, junior engineers usually are not expected to have necessarily a very broad knowledge of different disciplines, methods and tools; they need to have sufficient knowledge to execute the tasks that will be assigned to them, and the ability to execute them correctly.
One particularly important skill to develop is how long one should try to find out things on their own, before asking for help. Many people fall into extremes -- either ask for specific help at every step (which hints at incompetence for that task) or waste many hours or days following a wrong path when a 5-minute chat with someone could have pointed them in the right direction (e.g. "use this library").
So my advice would be to find out which are the kind of tasks that you are expected to do at this point, which tools (including programming languages, database, web server, etc.) that you need to know, and focus on doing a good job in those specific tasks.
At the same time, slowly start increasing your scope (e.g. by doing reading and playing with different tools in your own personal time).
My main practical advice would be to make sure you understand the requirements of the tasks that are assigned to you. It's very common that senior engineers take something for granted, as obvious, but junior engineers miss those implicit requirements. E.g. "of course it needs to be highly available, fault tolerant, and with sub-millisecond latency, duh!"
Participating in code review is great: if they're OK with it, try reviewing senior teammates' commits as well. You can learn a lot by questioning why particular decisions were made, and you might even uncover a bug or two.
you can't ask too many questions, BUT when you do get an answer, write it down!
There is nothing that shows lack of effort when you have to spend your time as a senior developer repeating yourself because the junior developer did not write it down or could not remember it.
That is the only thing I would say to you!
And good luck and keep hacking!
Every engineer and every team has different styles and preferences, and the only way to learn is to ask (and also work with them for a while). Alternatively, ask if there are any documents that outline established team behavior/culture.
People are always willing to praise, help out, and even promote guys with good attitudes.
Netflix needs/wants in-house recommendations because any external recommendation service risks drawing attention to their limited offerings. Netflix has around 20,000 titles for Americans, closer to 6000 it seems for canadians. That's only slightly better than a well-stocked blockbuster video. Nearly every old show recommended to me by friends, by actual flesh-and-blood people, isn't there.
Also, What happens to recommendations once the shows they recommend are dropped from the netflix lineup?
You have just got more criteria then Netflix implementation.
2.If salary offers are ridiculously low side, this usually indicates that there are problems with money in the company,or that company is offering something which will substitute for the low salary (really cool tech, everyone wants to work there, remote work, perks, etc.) Recently, it is mostly been the former.
3. Worldwide talent availability and competition from multinational corporations has made the engineering job market less lucrative in the US for engineers.
To answer your question, lftp  on the command line, cyberduck  on osx. Both of these tools are capable of connecting to sftp servers, too.
Also, sshfs (+ osxfuse for osx)  is definitely worth a try.
I've convinced several coworkers to buy it as well because it's so easy to use. My most favorite features is the ability to mount a server as a disk.
On a more serious note. If you ask for GUI clients here, Filezilla is still quite good. But better don't get it from SourceForge, as the package it with malware, adware, trojans and what not. Oh man, crazy how much SF messed things up in the past decade... but different story.
If you are working with others the first thing I would personally ask is what they use for communication (slack, IRC, e-mail, etc). If you are going to be part of a team where the majority of them work in an office it is very easy to be forgotten about or left out of things depending on what technology they are using and what the culture is.
I would also ask what the work hour expectations are and have it documented. Are you expected to be online from say 8am-5pm local time? I have seen some people told "just make sure you get your work done" but then let go because they were not making themselves available during the hours the rest of the team was online (even though their work was getting done).
In my experience perception plays a big role in working remotely. If the people in the office don't constantly hear from you or see you online the idea that you are slacking off because nobody is there to manage you starts creeping in.
Also don't be afraid to ask for the same type of perks non-remote employees get with regards to hardware/software/etc.
Does the company already have a good system in place for remote collaboration, e.g. Slack channels for asynchronous standups, shared calendars, Confluence documentation, screen sharing tools for pairing, Google Hangouts, a healthy PR and code review process? Those tools and processes will need to be habitual for you to be a productive member of the team.
The trickiest component of remote work is communication. Ask other team members how they collaborate effectively and the tools used to do so.
Working from home is a perk in itself but its not for everyone. Sometimes I find myself going into the office just to get out of the house.
Edit: Also, a lot of remote employers will want to meet face to face eventually. Make sure they offer to compensate for travel expenses and a clear duration in the terms.
I'm going to operate under the assumption that you're a remote worker applying for a job that involves working with in-office folks since that wasn't provided in the question and it's the only thing I have experience with. There are a few things I would recommend discussing/negotiating before choosing to take the job.
Make sure that the company is going to provide you with the equipment, appropriate software licenses and such that you need to do your job (or salary for you to afford the expense). Consider things like upgrade frequency, office supplies and other factors that are normally a given in an in-the-office job.
Discuss communication expectations and work/life balance. What communications tools does the team use? Are they appropriate for asynchronous communications or is the culture one of "tap the guy on the shoulder"? There's a sort of undercurrent of concern that rips through you when you're a remote worker that might have you feeling like you have to work "all the time", especially if your team is in a radically different time zone. Prior to accepting the job I ensured that my performance would be based on meeting project deadlines with appropriate requirements to be in meetings when they're scheduled (and none are scheduled at obscene hours of the night for me). My biggest concern was that being the guy not in the office would equate a perception of being the guy who is just taking a vacation or goofing off (those who know me would laugh at that because I love the work I do, however, I tend to work a lot from a family vacation home, so the appearance was a concern of mine). I write software and my most efficient times to work vary. Knowing that often I can get 14 hours worth of normal work done in 6 hours if I target doing it at the right time, I wanted that flexibility to be baked into my work contract. Provided my scheduling flexibility doesn't block the rest of the team (it doesn't due to unique circumstances of my job), or cause me to miss a deadline (it often results in me being early, instead), I'm free to work when I want and due to the added efficiency, that equates to hours/week of time that I get back.
The bottom line on that last point is be sure to have a very solid discussion on how your performance will be tracked. Aim for the most objective measurements you can get, and ensure that you have substantial input in deciding deadlines. There's always external pressure on deadlines, but if you can't be a prime component in that decision making process you run the risk of being given work that is not possible to complete on time, setting yourself up for failure. If your discussion is dismissed or the answer is "we'll figure it out", beware. Your manager is likely the kind who equates performance with "butts in chairs" and you will always be an empty chair.
Then, at month 10-11 of working there, begin looking for a new job immediately.
About 6 months later, when I was feeling better, I interviewed for a job closer to home. When asked about why I was only at my first job for 5 months, I answered that I left for personal reasons. The matter wasn't pushed, but I later felt like I'd blown it. Much to my surprise, I got an offer, and a good one. I'm still at this company 2 and a half years later.
My conclusion is that no job is ever worth staying in if you don't feel like you're doing anything meaningful. If I'd tried to stick my first job for a full year, I would have topped myself. I couldn't stand working like that. I discussed the faults of my old job with my new colleagues after I started here and they understood.
As long as you're not hopping jobs every few months, you should be able to convince your interviewer it was a one-off. Don't worry about trying to work a full year in a toxic environment. Move on if you need to. At the end of the day, you can put a spin on your resume, but you can't spin your personal satisfaction with your job.
I sense in your case you're dealing with passioned/opinionated people and you should take constructive criticism and advance yourself. But don't take shit from them.
Have your own opinion on things even if it's not the right one. I love reasonably opinionated conversations because I can learn new from those if I am wrong or incompetent in certain areas.
In the end you don't owe them anything and they don't owe you anything (aside from money).
Think of your job as a process of you helping the company with your talent and time. Move on if it's not fun for you and you don't learn anything new.
But they were right and it took me a while to appreciate this. Even so after two years I left my job to start my first company but the experience gained over those two years was worth gold later on and the combined knowledge of those people was immense.
I'd suggest you take a different attitude for a bit, assume they are really trying to teach you, engage them and eat up as much of their time as they're willing to give to educate you. Then, when you've really absorbed all there is to be absorbed (that could be today, I can't tell from your description) look for another place where you again can learn a lot. That's the best reason to change employers: that you've reached a plateau in what you can learn on that job.
1. Tell your boss you quit, because of the facts you point here. Tell your co-workers you quit, because you are not satisfied with the job. ( You will have done the best thing for the company if you do that ).
2. Find a new job/work and don't talk about why you quit your previous job in details. Just tell your new boss : "Well I wasn't satisfied with the team. I didn't have a chance to be valuable, because of their closed-culture. They didn't want anything more from me than being a non-thinking programmer.". Trust me, he will like this. If he doesn't you will end up in the same company
3. In between ... start working on an open source project with good reputation to gain back your confidence ( if you've lost something out of your job ). Even one Merged pull request is a big deal in those moments.
If all of this doesn't work. Let me know. I'm living in Berlin and I think I can find something for you if you want to relocate.
You can mention in your exit interview that your manager was nice and you were leaving due to a dysfunctional team if you want.
Honestly what you described does not sound that bad. You should think about other similar situations in your past that you have had with other people and try to see if you have a pattern of needing to be right. It is entirely possible you are externalizing some fault in your own personality.
Regardless, look at it as a learning opportunity. If you can't handle the various personalities in the world without it effecting you on a personal level, you're going to have a tough time.
Anyway that's gonna happen as you grow up
I also annoyed management by trying to start a salary spreadsheet. That was fun.
I stayed till August 2015 because of the 1 year thing and for a whopping $5,000 worth of options. But after I jumped, I discovered that a lot of people leave bad jobs within a year. I think it's okay as long as you don't do it more than once.
Lastly, would you trust someone you barely know? I wouldn't. Don't talk to your manager.
1. Life is short and software market is hot.
2. Get ready to leave but don't make it too obvious. ;)
'makes a basic distinction between alternative ways of reacting to deterioration in business firms and, in general, to dissatisfaction with organizations: one, exit, is for the member to quit the organization or for the customer to switch to the competing product, and the other, voice, is for members or customers to agitate and exert influence for change from within.'
Hope that helps you figure out whether to use your voice or your feet!
There's not even one example where they reacted in a "nice way"?
Seems you haven't told them how such thing make you feel?
Maybe it's not personality, and perhaps they don't know this stuff is bothering you...
Definitely talk to your manager, and try talking to your team as well.
Focus on observations/examples as well as how those situations make you feel.
I agree that life is too short, and IT is full of "difficult" people. Instead of running away from it, get better in dealing with them.
There is a first time to everything. If you move away, you are moving away from an opportunity to deal with things you never dealt with before. Your job is not so precious as you think. Try different approaches, be confrontational when you want to be, you don't have to be nice anymore, try to overcome this and you would be a much better person for yourself and others. Why do you have to be the one that goes to the manager, why cant you send your colleagues to the manager? Your manager might trust you more if you learn to deal with situations yourself.
It is possible some of my advice might seem "bad or condescending" but who cares I said what I wanted to say.
I happened to watch this old Andy Griffith show, it might be relevant.https://vimeo.com/66146806
After thinking about it some more, I would consider if you like what you are doing. There was several people I dreaded seeing everyday, but I also didnt like what I was doing and wanted to go back to doing something I liked doing. Both of those problems made it pretty easy for me to leave my job. If you like what you are doing, I would try to make it work or at least stick it out long enough to find another job doing that.
Old joke: "Personality conflict" is one of those code phrases for "Somebody here is an asshole"
Seriously, though, team members have certain styles, and teams fit together in a certain way. Most companies never figure out that you can take 4 or 5 great teams, remix all the people, then end up with 4 or 5 horrible teams. It's not skills -- a lot has to do with the way the personalities mix.
If you are completely out to sea -- unaware of how to continue -- perhaps you just name it and shame it. "Hey Joe, I see you're trying to teach me error handling again although I've been doing this longer than you have. Okay if I start doing the same to you?" Then start doing it.
Was working with a CEO of a small company once. I think they had around 100-120 employees, all knowledgeable about a certain part of tech. I was brought in also as somebody who knew what he was doing, but since I was working directly with the CEO, I kind of held back a bit to see how he worked.
Bad decision. He ran over me. The first time he mentioned something they had invited me in on, I tried to raise my hand. He ignored me. The second time I was a little more insistent. By Day 3, he started in on the same topic again, I simply said "You know, I've written a couple of small books about this and devised my own training material. But what the hell do I know?"
I wish I could say that solved the problem. It did not. He was still an asshole and we didn't get along. But I had to take what he was doing to me and do it right back to him for him to be able to see it. I got to start doing the work they had hired me for. If we had continued working together after that first week, it would have probably gotten very interesting!
Either you walk or give as good as you get. If you're shy and the others are domineering, passive and passive/aggressive techniques are just going to make it worse.
Biggest headache for a boss is getting team members to play nice with each other.
The ability to solve problems with ones peers is a desirable managerial quality. Interpersonal savvy is very much a learned & practiced skill. This could prove a huge opportunity for your professional growth.
Suggest reading up in this area, Robert Bolton's book on People Skills is a good place to start > http://www.goodreads.com/book/show/65327.People_Skills
Ultimately, moving on to a new company is easy. But dealing with difficult peers never fully goes away.
But if you don't find a way to get along with them that suites you, then I would recommend going on interviews as soon as possible to gauge your markets reaction. Just don't say anything bad about them; you can always find an arbitrary difference between two employers and pretend that difference is a little more significant to you.
Don't go into this with any expectation that anything will get fixed. Most likely, the manager will take your concerns to your co-workers and tell them to fly right, they'll make a token effort for a couple of weeks, and it'll go right back to the way it was after that.
The point is, I was miserable, and after 3-4 months I knew it was not the right team for me. I found a new job quickly (networking, kids!) and once I found out my new start date I had a talk with my immediate manager and told him why I was leaving. I told him about the toxic culture. I told him about being made to feel stupid because I had tried to build process improvements which amounted to moving someone's cheese a few millimeters. He understood, and was grateful. I told the HR person about the team dynamics. I told her that this toxic attitude towards change would continue to drive talented people like me out of the organization. She profusely thanked me and said that it had been the best exit interview she had ever had.
Fast forward 6 months on my new job, and I'm unhappy here for entirely different reasons. Time to start looking again!
I absolutely do think you should talk to your manager. If you don't, you are missing an opportunity to practice the skill of having difficult conversations, and you're short changing whomever comes into your job after you, who'll have to have that conversation, too. Plus, your manager might surprise you. She/he might have a way to make you happy! Do start looking for a new job today. And for the love of all that's holy, make your next interview all about figuring out what the people will be like to work with. Don't come to the interview from a place of "I have to get this job." Come at it like a date. You're trying to arrive at a mutually beneficial fit. Don't try to impress them; just be yourself and see if there's a spark!
You don't owe them anything in the United States unless you're under contract. What you kind of do owe them as a good person is to talk to your manager before deciding to quit.
As a side note, culture fit is a two way road, but from the post you wrote they are all monster while you bring all the objectivity and experience. You might want to review the way the story is told, because, frankly, there are quite some red flags that come from it.
But I'd advise (depending on your circumstances of savings, chances of getting a new job soon etc) to not simply quit, but use a bit of time to really put yourself in a strong position to get a new job w/out the pressure of needing one.
if its a big company maybe you could transfer to a new team ?
I started looking around and I got a job offer. As soon as I was going to accept the job offer, someone at my current employer discovered that I was planning to leave and my boss caught wind of it (I suspect I left my computer open). My boss pulled me aside and actually convinced me to stay because of the prospects of success. The company had already given me big bonuses and had very good benefits. That was four months ago. I made the choice to stay in a toxic environment just for some arbitrary gain.
Three weeks ago, out of seemingly nowhere, I got fired. I let go of a valuable opportunity because I convinced myself of some arbitrary gains by staying and I had fears of leaving.
I was desperate to find another job and I accepted a terrible offer using terrible technology. I thought I was fucked; I was severely depressed because it was the first time I had gotten fired from a serious position. But I got lucky. Although I'm now working at another company with terrible technology (ASP.NET Web Forms), the people are the nicest and sweetest coworkers I've ever met. I'm happier here, working with shitty technology and shitty prospects, just because my environment is that much better. And I'm not settling here: I am constantly looking for better positions (and contracts) and looking to advance my career until I find the company that I fit in and is a good fit for me as well.
DON'T SETTLE. LEAVE. If you're not happy, don't stay in the position you're in. Unless you need to build your resume or gain experience, there's no reason for you to stay faithful to a company with a toxic environment. You're going to be there eight hours a day, and if things don't work out they will IMMEDIATELY fire you and you'll be fucked, like I was. Usually a toxic environment simply means that you don't fit, and they will let you go simply for not being a fit. Don't make the mistake I made; leave.
One last thing: good developers tend to be overly critical, but that doesn't mean all overly critical people are good developers or even good workers. Many developers have terrible social skills and are unable to properly and professionally express their opinions or thoughts. Don't let anyone tell you how you should be treated or what you should be okay with. If you have a gut feeling that the people you work with are unprofessional, don't brush it off as "oh, they're developers. That's how all developers are." This is a fucking cop-out. I have met plenty competent developers who are able to give constructive criticism without being a complete dick.
Try to find a way to make lemonade with the lemons you work with. Maybe you'll teach them a thing or two. Also, possibly some of their criticism is valid, regardless of how poorly delivered...
How long have you been there so far?
Failing that, I'd find a new job; you don't owe the company anything (literally) and you owe it to yourself to not be miserable.
There was an encrypted note-taking app but it's not developed any more.
The generic solution is to use GnuPG.
Then after a few days copy it onto other platforms. Like Medium (with a link back to the original) and LinkedIn Pulse (if it makes sense for your audience).
Basically being closer to the source of money and to decision making people is a good idea.
You probably still don't know about the hierarchy that exists in the industry, but I'll just say that VCs are usually in the best position.
Here you can find the FullStack Redux Tutorial: http://goo.gl/QYLB3s
It is a great starting point if you want to learn more about Redux :)
Facebook also came out with a storage interface and state management library that is used to manage unidirectional data with a backend called Flux https://facebook.github.io/flux/
And a lot of the cool kids these days are using a Flux-like state management system called Redux - http://rackt.org/redux/index.html which is roughly based on the immutable patterns from Haskell/Elm.
That almost sounds like a class structure type thing. And, I find even with a jenky interface and feature set I tend to gravitate towards social networks with a population past a certain threshold. I couldn't tell you that threshold as a number, but it's got a healthy glowing feeling, like everyone is contributing regularly with sincerity and enthusiasm. That kinda stuff that grows mostly organically.
If you are interested in building such a product yourself and want to approach it more from the multiplayer document annotation platform angle than the specialized book forum angle the Memex, Ted Nelson's writing (especially Literary Machines) and Wikipedia's reference templates are also worthwhile sources of inspiration.
My point being that "database design" is non-trivial to the point that "cut and paste" is at the application level not the schema level.
I did the same thing once, and then never again. I developed a product for a year in my free time. Everything was finished, polished, all the features were fully developed, and it was ready to go. What happened? I 'launched', a handful of users registered, there were a dozen posts, and that was it. Only in that moment, did I realize it wasn't that great of an idea in the first place, and how absurd it was to invest a year of my time before getting feedback from my target audience.
What I do now is try to launch asap. I get a rough concept up and running, and launch in a weekend, a week, or a month. I developed one site over the course of 48 hours (from idea to working beta), launched, and it had 2,000 registered users in less than a day. It still failed a year later. I launched another site after a month of development, and that one had 3,000 users the first day, and now it has a million and continues to grow.
By not launching, you're wasting time. There's a 95%+ chance the product is going to fail, you'll get a tiny spike of traffic day one from your marketing, and that'll be the most traffic you ever see. That's why you should launch asap. If you invest a few weeks, and it fails, that's great, you proved the idea doesn't work, and you move onto the next. You can launch a dozen products and services in a year this way, identify the failures, and when one appears to gain traction, then you can flesh it out more. I don't think my site had a FAQ until it had 25k+ users, a support section until it had 50k+ users. It didn't get a ToS until it had 500k+ users. Launching is a good way to validate the core idea, before you invest all the time in the extras.
Second, as Gustamaximus said, you are obviously scared to be proven wrong or fail. That is natural. None of us want to experience the disappointment of believing in something so badly we spend months working on it and then discover no one wants what we built.
Other scary thoughts in your head right now probably...
What if the launch results in a big NOTHING??!! No users, no interest, just nothing. Paid google click traffic that just moves on after spending a split second on your front page.
Even worse...what if there is a bug in your code and you accidentally charge your first user a million dollars on their credit card instead of your modest 10 dollars a year subscription fee and they Tweet their 100,000 followers how much your service sucks?! You will never get user #2 and your service will be dead within 5 minutes!
Yeah...these things could happen...but, most likely not.
All the difficult work is all ahead of you. Marketing, sales, retention, customer service, bug fixing, re-positioning, competitors etc etc.
The launch is a non-event compared to all that's still ahead of you.
Pick one of them. Launch it. See it through a few iterations, because (spoiler alert!) it won't be perfect at the beginning. What you launch will probably not get traction. If you've never launched anything before, you won't believe me. But this is both a liberating and terrifying thing, so it's important to accept that you will fail to live up to your hopes.
The more you're convinced that you won't fail, the less you'll risk actually failing at something. The more you'll fall back on your conviction of being smart enough to delay launch. The more you'll build features instead of launching shit to make things that people will use.
Today, say to yourself that you will adapt. That the biggest adventure is yet to come, and that you don't know what will happen, but even then, you will face every challenge down.
Then tomorrow, JUST FUCKING LAUNCH IT.
Not launching = failure = not a bad thing, but just learn from it and launch!
p.s There are a lot of people alone in this world.
The really hard thing is marketing -- getting people to know and then care about your service. Get the tech stuff out of the way and move onto this. It is hard. The first people who use your service will give you invaluable feedback.
Stick a BETA on it somewhere and go live ASAP.
My favourite quote in recent memory is Markus Frind, of Plenty of Fish fame. I'm paraphrasing here, but he says launch something that just sort of works and then take it from there.
But it seems like you're well beyond the point of something that just works at a minimum, so I'd say don't worry about anything beyond getting these products out. A lot of people don't even get to the point of having something to launch for a variety of reasons, both internal and external.
Alternately, pretend a competitor is coming out with a similar service and it's a race to go live...
I know this is a gross oversimplification but it seems your overthinking it and need to do.
As other said, don't launch both at the same time, don't focus too much on "will it work", for "completely finished" product it's no longer the right time.
I'd try to review your expectation:-- One of them will take off like a rocket and I'm convinced of itThat's giving you too much pressure, just wait, see and iterate accordingly.
Doing a closed launch before the actual release date is another thing that can help feel "everything is really ready to go".
Any time you feel like this, assume it's self-delusion because it probably is.
Stop worrying so much about failing and just expect to fail a lot, then it won't seem so scary. Launch this thing. Try to make it work. Then work on something new that genuinely interests you more. Follow your interests and work hard.
You are going to fail, but if you don't give up, you are also going to succeed.
Stop reading these comments, get off HN, and LAUNCH THE DAMN THING, fuck breakfast.
So what do you have to loose? I mean, could you write what you think you will loose?
I work with people like you all the time in my coaching business.
Allow me to show you the light at the end of the tunnel.
A comment box isn't going to do this justice, so email me at Joe at thesuperhumanproject.com and I'll help you through this.
For the good of the community, we can do a write up of what we discussed or we can keep it private. It's up to you.
Then again, it could be a way to cover up for a lack of content. Set the speed of light to be faster, and it might theoretically make it so a species with massively advanced technology could reach the edge of the universe. More convenient and realistic than an invisible wall.
The first context is the ordinary one in which the universe is roughly the container for everything that is including ourselves.
The other context is one in which the universe is a simulation of a container for everything that is including ourselves that is indistinguishable by us from an actual container for everything that is including ourselves.
It's fine to use the latter definition, so long as one recognizes that the use is very odd and problematic and any conclusions one draws while using it are simulated conclusions about the simulated container and not conclusions about the actual container for everything that is including ourselves. To put it another way, if the universe is a simulation then "light" and "speed" and "C" refer to elements of the simulation and need not have a one to one correspondence to entities in the actual universe. Human knowledge can only be knowledge of the simulation.
Our knowledge is limited to things it is possible for humans to know. If we're in a simulated universe, then we can only know about the simulation.
Or we need to buy the FTL DLC
const LIGHTSPEED = 299_792_458
Alternatively, see if different equations scale differently based on the speed of light.
That said, why create a "tick" when the perception of that tick can vary by individual? When I go into code mode, 10 hours can slip by in an instant, and I'm not hungry or thirsty until I come out of it.
Perhaps it's just an affectation of focus, as time still "ticked" by at it's normal rate.
Einstein said that the effects of time move more slowly the closer you get to C, so it makes sense that C would be the univeral "tick" if this was a simulation. As evidenced by Mars rovers and Voyager, an earth clock on another planet or in space still ticks at the same rate (Voyager and Mars are moving through space at the same rate we are moving around the sun, about 61,000km/hour).
There's no other reason for light to move at a steady speed, and nothing apparent that's stopping it from going faster.
This one, for example, even looks "identical". http://www.twenth.com/
These look polished enough that your customers won't know that you purchased a theme v/s hired a designer (they don't care anyways)
Once you have enough revenue coming in, you could then hire a designer to create a custom website for you (if you still really want to).
As a co-founder? Employed with salary, full time/part time? Contractor?
You can check out monthly freelancer/who wants to be hired threads on HN. You can check out designer news (HN for designers). You can hunt on dribble. You can put an ad on your local job board.
The whole idea is that we managed the infrastucure and you can launch any docker container that you want.
But we have since changed our idea to be more of a prototype hosting platform where you can easily host and get started really quickly.
I would really like to dicuss the idea with you, you can catch me on social media with username @kevinsimper also on Skype.
https://www.dotcloud.com/ was originally built by Docker creators, then sold)
https://www.tutum.co/ (bought by Docker a few months ago)
A lot of companies prefer pair programming so they can talk through problems with a candidate, both to get a feel for how they approach their work, and to make sure they aren't blocked on anything, given the limited amount of time. Was your interviewer talking with you while you paired?
The screen is a one hour onsite pairing session followed by a final round that is a day of pairing using a proper workstation: One computer, two monitors and two sets of mice/keyboards. You pair with one person in the morning and another in the afternoon. It's very relaxed (you take turns "driving") and it gives you and the interviewers a lot more information about each other and your potential place of work. It also gives you enough time to adjust to the process if you are nervous. I don't think I'd do it any other way going forward.
Usually companies who engage in these practices have tendencies to micromanage their personnel down the road.
That said, our best hire was the one person who rose to the occasion and solved the problem we were asking. For that reason, I would do it again.
Edit: it may also mean the company you are interviewing at does pair programming. If you don't like pair programming, the interview is a good time to bring it up!
I don't actually consider node/JS the most ideal choice for developing good backend habits if back end development was your central goal. But it will introduce you to a JS development process that is a lot better structured than you are likely to commit to when working with JS only on the client side. It will also make it easier to restructure with less of a mess if you realize you need to move between thin/online and fat/offline clients.
I'd do the API in Rails, just because there are probably more resources available and the framework is very REST oriented. Don't know much about Node though, could be just as good.
I mean, sometimes a story slips through, and a subthread happens, but generally it feels like there's a big hard clamp on that. Maybe I'm projecting.
>But there is no free speech on private property.
You are right. But you know what drive proponents of free speech batty? When people don't understand the philosophical underpinnings of why we advocate for free speech. And this happens all the time on HN. Hopefully, this is because of all the non-U.S. visitors that come to this site. For those, a little explanation. We come from a culture of free speech. We think it is good, and we are the descendants of people who thought it was good. We were taught that it was good from when we were small children. Our experiences are that busybodies and tyrants are the ones who push for censorship and work in the shadows. And those are some of the reasons why freedom of speech is enshrined in our constitution. We do not think: because it is in the constitution, therefore it is good. So to us, it is not like deciding to drive on the left or the right side of the street. Each being perfectly reasonable, and which ever way they do it where you live is an accident of fate. And we do not think that free speech is only reserved for political topics, or when talking to governmental officials.
When someone starts to mention legal technicalities of free speech, it makes me want to barf on their shoes, because they are completely missing the point. We grew up with it as a minimum expectation of decency. A fundamental human right. Slaves and servants don't have the luxury of free speech. Demand more of yourself and your fellow citizens.
This sort of thing tends to ebb and flow with election cycles, especially for U.S. based commenters. It's going to get more annoying as the next year goes on, but for whatever reason people feel the need to share their opinions on this more during important elections (whether the majority of people consider it worth reading or not).
IMO, silent tolerance (up to a point) is more discouraging than engaging with the nonsense as it gives them nothing to push back against. I'm also reminded of this post of an IRC chat room where (apparently) one person is arguing with themselves in an otherwise empty room about some kind of political point. While you may want to believe you are engaging with a worthwhile opponent, you could be talking to that person, and you just don't know it.
Also,"The chief complaint..."? Are you representing more than your own opinion here?
The system works as is. We don't need a sweeping moratorium. That would go bad places.
Flag or downvote and move on. Give more of your energy to engaging constructively with items you see more value in, less to the things you find tedious. Your desire to completely ban something so you don't have to make any effort to mentally filter out certain types of things is the kind of position that goes very unhealthy places.
It's sort of like how Hacker News is for "anything that good hackers would find interesting," which sounds like it means something but really doesn't mean anything specific, and probably just resolves to "anything that correlates with the interests of the mods," like every other moderated community. Other than branding, what even is the point of using "Geek" at all?
But to actually answer you question, personally, no. I think there are already tons of sites which cater to "Geek culture" (or nerd culture or... whatever) of various niches, and of course if what you want in HN, but with invitation only, there is lobste.rs. Someone can basically set what you're describing up as a subreddit. I also don't like invite-only communities on general principle.
How would that be different than what we already have... right here on H/N?
Shameful plug (hope this is ok, this is my first HN comment), but I'm also working on a "social network for geeks" but is more specific to developers and designers: https://codebee.io/ It's a big hurdle to keep users active but it's a side project and haven't been able to devote a lot of time.
SQL is great for choosing which columns to get out of multiple tables, somehow combined, as well as to filter which rows. If the end result is ready for R to use in modeling, that's great.
R can struggle to index and manipulate large datasets for combining/selecting columns and filtering rows, but that's the really nice stuff in SQL. They work well enough together and it's really no big deal to set both up.
you can use one in conjunction with the other;
R is a general programming language with a huge library of mostly statistical analysis routines.
SQL is a way to get data in/out of a database
You might want to use SQL for trivial analyses, and anything more, maybe use R. But you can use SQL from R to get the data.
Could you? Probably. Would you want to? I highly doubt it.
What R brings to the table are numerous statistical methods packages and some good data visualization packages. With just a few lines you can apply some sophisticated techniques and produce beautiful visualizations.
SQL can indeed do some complex analytics, but they're very difficult, so R is the easier platform for statistics and machine learning. I did a Coursera class recently in which we had to do matrix multiplication with SQL and even that was a brain teaser of a puzzle. The advantages of doing analytics within a database are (a) leveraging the query optimizer to speed up your analysis and (b) you can make the analysis available to other users of the same system via a view or stored procedure, so they don't have to do the same work twice.
Also, don't follow implementation. Follow the spec, and implement against it, not against an existing implementation.