More power to you if you find yourself actually meeting business needs over the company's own internal programmers and systems folks.
I am, of course, trying to effect change from within the org I am employed by.
Excel... how people use excel and the amount of waste that happens just because they don't properly know how to use 'vlookup' or 'if' simply just boils my blood.
Lets write most of our code ourselves, get independent from external actors, but we are slow now, glacial and distributed to reinvent a lot of wheels, while others outpace use in our domain. We should use more librarys.
Want people to be happy? Give them no benefits, no health care, no 401K, no bonuses, and plow all of that into salary. People would rather have bragging rights about how much they make. Doesn't matter if you point out that they get a bigger package when the employer pays the health care (if the employee pays then they pay with after tax money).
It is mind blowing to realize that people that are way smarter than me are stupid about money. But I've definitely seen that pattern.
I ignored what they wanted and gave them good health care, did 2:1 match into their 401K, and did bonuses so we didn't get double taxed (corporate and personal).
(Disclaimer: I don't actually manage them. I'm kind of a lead, but nothing more.)
* Underestimation of difficulty whether through cynicism (burn the devs) or cluelessness
* Inadequate training and expectation devs can just piggy back learning technology x from scratch whilst writing production software using it
* Trying to use one off contracts as a way of building resellable products
* Insistence that all devs time must be billable and trying to defy gravity in ignoring skills rot etc. through lack of investment in training
* Expectation that devs can be swapped between technologies without problems
* Swapping people in and out of projects as if this will not affect progress
* Deliberate hoarding of information as a means of disempowering devs
All of this inevitably leads to a bunch of pissed off devs. The ones that are happy to eat it become the golden boys and get promotions. Those that point out the bullshit leave once they can and are replaced with the desperate at the bottom who sooner or later arrive at the same position of wanting to leave once they realise what's going on. I think tech can be pretty miserable if you are not in the upper echelon of lucky types that can score a position at a Google, Facebook etc.
Oh and a couple more:
* Give no feedback unless things go wrong
* Treat your highly educated, intelligent and motivated devs like children by misusing agile in order to micromanage them
You might think startups are small enough that this couldn't happen but that was actually where my worst experience was. The founders are visibly in a meeting with a couple people, maybe "suits", maybe not. They come out of the meeting and the next day your priorities are rewritten. Cool beans, that's a thing that can happen and that's not my issue. My issue is, why? What are the goals we are trying to hit now? What's the plan? Why is that better than the old plan?
This is especially important IMHO for more senior engineers responsible for architecture and stuff, because those matters can greatly affect the architecture. Telling me why lets me start getting a grasp on what parts of the code are long term and what can be considered a short term hack, what the scaling levels I need to shoot for, and all sorts of other things that are very hard to determine if you just come to me with "And actually, our customers need a new widget to frozzle the frobazz now more than they need to dopple the dipple now."
Not necessarily the biggest issue, there's a lot of other suggestions here that are probably bigger in most places, but this is one that has frustrated me.
(I'll also say this is one you may be able to help fix yourself, simply by asking. If you are in that senior role I think you pretty much have a professional obligation to ask, and I would not be shy about working that into the conversation one way or another.)
* Spending too much on marketing/sales before people want the product. They usually just end up burning their brand if the product is too low quality.
* Too much focus on building multiple small features rather than focusing on the value proposition.
* Trying to negotiate deadlines for product development. "We don't have two months to finish this. Let's do this in one." In software estimation, there's the estimate, the target, and the commitment. If the commitment and estimate are far off, it should be questioned why, not negotiated.
* Hiring two mediocre developers at half the salary of one good developer. They usually can't solve problems past a certain treshhold.
* Importing tech talent, rather than promoting. Usually the people who have built the product have a better understanding of the tech stack than someone else they import.
* Startups that rely on low quality people to skimp on the budget. These people later form the DNA of the company and make it difficult to improve, if they're not the type who improve themselves.
Here's what happens when a manager tries to fill tickets himself: his sense of control of the project is derived not from relationships of trust and cooperation with his reports, but from direct involvement in the code. So naturally, any challenging or critical piece of code ends up getting written by him (because otherwise, how could he be confident about it?)
The manager is essentially holding two jobs at once so they end up working late or being overly stressed at work.
The devs will feel intimidated to make architecture decisions, because they know if they do something their manager doesn't like, it will get refactored.
They will also feel as if they are only given the "grunt work" as all the challenging work is taken on by their manager.
The code itself is in a constant state of instability because there is a tension between the manager needing the other employees' help to get the code written on time, while also needing to have that complete control and mastery over the code that can only come from writing it yourself. So people's work gets overwritten continually.
This is very bad and it's very common - managers should learn to delegate as that is an essential part of their job. If they can't delegate they should remain as an individual contributor and not move into management.
* Reorganizing seemingly for the sake of reorganizing. Result: Every time the new organization has settled somewhat and people know who to interact with to make things flow smoothly, everything is upended and back to square one.
* Trying to make our products buzzword compliant without understanding the consequences - we've on occasion been instructed to incorporate technologies which are hardly fit for purpose simply because 'everyone else is doing it' (Where 'everyone' is the companies featured in whatever magazine the CEO leafed through on his latest flight. Yes, I exaggerate a bit for effect.)
* Misguided cost savings; most of what hardware we use, we buy in small quantities - say, a few hundred items a year, maximum. Yet purchasing are constantly measured on whether they are able to source an 'equivalent' product at a lower price. Hence, we may find ourselves with a $20,000 unit being replaced by a $19,995 one - order quantity, 5/year - and spend $10,000 on engineering hours to update templates, redo interfaces &c.
* Assuming a man is a man is a man and that anyone is easily and quickly replaceable (except management, of course) - and not taking the time and productivity loss associated with training new colleagues into account.
Edit: An E-mail just landed in my inbox reminding me of another:
* Trying to quantify anything and everything, one focuses on the metrics which are easy to measure, rather than the ones which matter. As a result, the organization adapts and focuses on the metrics being measured, not the ones which matter - with foreseeable consequences for productivity.
The worst is when you get two or more managers attending the same meeting. Then nothing will get done as they eat up all of the meeting time arguing about business rules, magnifying the complexity of the system until you end up with some Rube Goldberg chain of logic that they will completely forget minutes after they've left the meeting. A good manager knows to trust their employees and only intervenes to make sure those employees have the resources they need to do their jobs. The most effective managers are humble and respect the expertise of the experts they hire.
There seems to be some sort of quasi-religious belief in the fundamental averageness of humans; consequently the difference between developer salaries at any company varies by maybe 50%, whereas the productivity varies by at least a full order of magnitude.
Until "management" realizes this, the only way that a developer on the upper end of the productivity scale can capture their value is to found their own company. I sometimes wonder what would happen if some company simply offered to pay 3X the market rate and mercilessly filter the results.
The first chapter says: "The major problems of our work are not so much technological as sociological in nature." Sorry Google Memo Dude. DeMarco and Lister called it in the 80s.
Speaking of DeMarco, he also wrote a book about controlling software projects before Peopleware. Then in 2009 he denounced it. 
To understand controls real role, you need to distinguish between two drastically different kinds of projects: * Project A will eventually cost about a million dollars and produce value of around $1.1 million. * Project B will eventually cost about a million dollars and produce value of more than $50 million. Whats immediately apparent is that control is really important for Project A but almost not at all important for Project B. This leads us to the odd conclusion that strict control is something that matters a lot on relatively useless projects and much less on useful projects. It suggests that the more you focus on control, the more likely youre working on a project thats striving to deliver something of relatively minor value.
: https://www.computer.org/cms/Computer.org/ComputingNow/homep...: https://en.wikipedia.org/wiki/Peopleware:_Productive_Project...
* Building a one more generation of product than the market supports (so you build a new version when the market has moved on to something new).
* Rewarding productivity over quality.
* Managing to a second order effect. For example when Nestle' bought Dryers they managed to 'most profit per gallon' which rewarded people who substituted inferior (and cheaper) components, that lead to lower overall sales and that leads to lower overall revenue. Had they managed to overall revenue they might have caught the decline sooner.
* Creating environments where nobody trusts anyone else and so no one is honest. Leads to people not understanding the reality of a situation until the situation forces the disconnect into the mainstream.
* Rewarding popular popular employees differently than rank and file. Or generally unevenly enforcing or applying standards.
* Tolerating misbehavior out of fear of losing an employee. If I could fire anyone in management who said, "Yeah but if we call them on it they will quit! See what a bind that puts us in?" I believe the world would be a better place.
There are lots of things, that is why there are so many management books :-)
1) believing you can dramatically change the performance of an employee -- it's very rare to save someone and less experienced managers always believe they can.
1.5) corollary to the above: not realizing the team is aware and waiting for you to fix the problem and won't thank you for taking longer to do what's necessary.
2) believing that people don't know what you're thinking -- people see you coming a mile off.
3) thinking you can wait to fix a compensation problem until the next comp review -- everyone waits too long on these.
4) believing HR when they tell you that you can't do something that's right for your team -- what they're really saying is that you have to go up the ladder until you find someone who can force them to make an exception.
5) not properly prioritizing the personal/social stuff -- at least this is my personal failing, and why ultimately management has not stuck for me.
6) believing your technical opinion matters -- I've seen way too many VP's making technical decisions that they are too far from the work to make, trust your team!
It'd be fun to see a list of these from the non-management point of view. I'd start off with the inverse of #6 above:
1) believing your technical opinion matters -- the business is what ultimately matters.
- Focusing on fixing problems, rather than preventing problems
- Acting as yes-men to bad upper-management strategy, thereby creating a layer of indirection between the people who think it's a good plan vs the engineers who can explain why it's not quite that easy
- Trying to use software tools (e.g. Jira's burndown charts) to quantitatively/"objectively" measure engineers
* Preaching about the virtues of a flat organizational structure, but making unilateral decisions.
* Hiring people for a particular challenging job, but have them work on menial unchallenging tasks.
* Creating multiple layers of management for a tiny team.
* Facilitating post mortems that would be better facilitated by a neutral third party.
* Using vague management speak as a deliberate strategy to never be held responsible for anything.
* Rewarding politics with promotions.
* Marginalizing experienced employees.
* Talking too much about culture.
* Trying to be the company thought leader instead of helping people do their best work.
* Assuming that everyone underneath you views you as a career mentor.
* Negging employees.
* New hire managers: Firing incumbent employees after youve only been on the job for a few weeks.
* New hire managers: Not doing 1:1s with everyone who reports to you.
* New hire managers: Create sweeping changes like re-orgs after a few weeks on the job.
* New hire managers: Doing things a certain way because it worked well at a previous company.
* New hire managers: Changing office work hours to suit your personal life.
(Similar problems can happen when a bunch of people with no management skills decide to found a company and start hiring people.)
Estimates get shortened. Technical decisions are overruled for business or political reason. Warnings about undesirable outcomes are ignored. Sheer impossibility deemed surmountable.
I feel this is the worst mistake by management because the technical people are the ones who suffer for it. Overtime, inferior software, frustration, technical debt, lack of quality, are all things management doesn't really care about because they can always just push people harder to get what they want.
What I mean by technical management is the following:
* onboarding new developers: showing them how to get the dev environment going, how to debug, how to use testing infrastructure, configuration management
* propagating information about design rules: documenting and evangelization of contracts between different different pieces of code, and all the various rules -- what must be authenticated, what must be logged, how to consistently check for access rights, which common module/library to use for what, etc.
* enforcing software development lifecycle: making sure there are design reviews/sign off/etc
It seems that managers offload a lot of the above to senior roles who rely on force of personality and personal effort to get this done, which creates a lot of randomness and also stress. Devs often don't learn these things except by creating breakage and then relying on experience or institutional knowledge.
It's very strange that on the one hand when it comes to corporate policies such as vacation time and provisioning productivity software, or even using the bug tracking system, there are handbooks, mandatory trainings, lots of online resources, etc. But when it comes to the technical rules such as which library to use, we pass to a medieval guild system of ad hoc 1 on 1 mentoring over Slack.
But perhaps I've just been working in the wrong companies.
Everywhere I worked, there's always one "super star" who keeps getting promoted for shipping something quick that looks good on the surface, but did so either by introducing massive amounts of tech debt (beyond what would be acceptable for an MVP), or by shitting on everyone else (working in a corner, ignoring any request for help, ignoring their direct reports, or generally at the cost of all of their other duties).
Makes everyone else look bad and them look good, and generally creates a pretty toxic atmosphere until management gets it (at which point its usually too late).
None of this was really necessary. Every single year, they watched the backlog of work gradually climb over the course of the summer. Then, around September, they began insisting on overtime at psychological gun point to try to clear the backlog. It would have been entirely possible to allow people who met certain quality standards to work some overtime during the summer and cap how much could be worked. People could have competed for overtime slots instead of feeling forced into it. It would have worked vastly better for everyone.
Of course, an elegant solution like that takes a bit more planning on the end of management. Simply demanding extra hours at a certain point is a simpler, brute force method. But, I felt it had a lot of downside to it and was mostly avoidable for the company in question.
It makes me wonder how many companies basically create drama of this sort. Because this crisis was entirely created by management, IMO. There was zero reason they had to wait until it hit a certain volume and then force overtime on us.
I got the luck to work with great managers at amazon. From what I've seen, programmers are driving the company there - or at least, they have their word to say, often, and power that comes with it. On my team, decisions relative to product development were clearly strongly driven by us. Seems to work pretty well for amazon.
Haphazard task assignment - I build a feature, then when they need an enhancement, it often gets given to someone else with no understanding of how it works, even though I am free.
Cargo culting in general. We do "Kanban" just to say we do, despite it having zero relevance to how we actually work. It's buzzwordy. Insistence on daily standup despite having very good communication and everyone knowing what everyone else is doing, were a small team in an open office.
Pushing for faster code review and generally treating it as a negative thing that just slows us down.
Previously we actually hired more devs to "help" get a project out the door - I think we all know what the mythical man month has to say about that.
Having to argue about basic security practices. I got in a heated argument about how we needed to encrypt temporary passwords even though they were system generated. I'm still angry. They wanted to be able to look them up for users. Sigh.
One of your teams write messy code? Don't try to educate them. Instead enforce strict coding standards that forbid all but the most basic complexity. Everyone else now have to make their code more verbose and objectively worse, while the problem team still writes bad code but now they make even more of it in a neater formatting.
2) Raise wages only for people who threaten to leave.
3) Run a high tech software development shop but have an IT department that assumes everyone only ever need Excel and Outlook.
Ports are blocked. Local computer admin is locked. Updates are forced, delayed and centralized. Hardware is underpowered. Network blocks ping.
4) Demand to be in full control.
Make sure nobody does anything you don't understand. Shoot down experiments you can't see the point of, even if they're small. Hire skilled and experienced people, but demand that you can understand everything they do.
5) Let random people deal with hiring and interviews.
Hiring is both a hard and sensitive process. On one hand you are giving people an impression of your workplace, and on the other hand you are trying to evaluate the skill of someone who has a different skill set than yourself.
Giving this job to some burnt out elitist asshole who throws resumes in the garbage because they did or didn't include a cover letter, or a wannabe drill sergeant who tries to be "tough" and "test them under pressure" during interviews, gives you a bad rep in tech circles and doesn't help you hire skilled people. Giving it to someone who can't be bothered to reply to applicants or update them on rejections is also shitty.
6) Open fucking landscape workplaces.
M: How long will this take?
D: Three weeks.
M: That's too long, we have to demo at a trade show in two weeks.
D: Fine, we can take out half the features.
M: No, we have to demo in two weeks, with all the features, end of story.
D: It can't be done, end of story.
M: Do it anyway.
D: We can't, what your asking for is literally impossible.
M: Fine, I'll loan you three more developers.
D: No, that won't help. Haven't you read The Mythical Man Month for crying out loud?
M: Of course it will help, how can it not help?
D: Nine women can't make a baby in one month.
M: That's not really relevant, get all the features done in two weeks.
D: Then why did you bother asking me how long it would take in the first place?
M: Just do it.
D: ~grumble~ -- storms off in a huff.
2 weeks later.
M: Is it done?
D: No, I told you it wouldn't be done.
M: Oh, OK. Well how long will it take to finish?
D: Another week.
M: OK, fine.
Everywhere I've worked, the folks running the show have too much ego and political capital invested in products or projects that are turds. The result is massive financial losses for the business.
* Short-term thinking ("we don't have time to fix the tech debt, we have to get something on the board this quarter")
* Over-resourcing projects from the start, rather than letting a small number of employees germinate it and set it on the right path
* Punishing people, often indirectly, for taking risks, conducting experiments, doing quick prototypes, etc
* Frequent shifts in direction, priority or emphasis. If "everything" is important at one time or another, then nothing truly is
- Letting whatever customer screams the loudest dictate product behavior, and then effectively alternating product behavior based on which customer is angry this month
- Deferring technical debt until a customer screams
- Hiring unreasonable product managers who have unreasonable expectations. (This just leads to a lot of time being burnt in haggling and a much worse product delivered.)
- Treating software as an art project, getting obsessed with pixels and fonts instead of functionality
- Not paying enough
- Interrupting programmers constantly for trivial matters
- Allowing the entire organization to interrupt a developer at any time because he's unofficially become a "go-to" person
- Not backing up critical processes when departments interact. (This is the information needed when there is a bug, support escalation, ect.)
- Expecting developers to handhold people in other departments
- Micromanaging task priority, assuming that a developer jumped on a specific task and completed it instantly
* Management is always right.
This truism is built into the entire fabric of software development: whether your process is an agile one where the product manager has ultimate knowledge of what is needed and on what timescales; the project that is delayed not because of bad planning or poor company organisation but because the developers are not working hard enough; that the only variable that affects the business is how productive / expensive the developers are - all the factors that describe how effective the management is are completely ignored or irrelevant. The list goes on and on and described in better detail in all the comments here.
Of course the solution to all of this is better data. You can be sure that the volume of data is inversely proportional to the strength of belief of the above statement. This leads to the second fundamental mistake that management makes:
* Not reading High Output Management by Andy Grove.
- Not changing their minds often enough.
- Generalising past negative experiences and applying them to new situations without properly acknowledging key differences.
- Not recognising the strengths and weaknesses of individual employees - They prefer to just throw more engineers at the problem as though they were rocket fuel.
- Not letting engineers feel a sense of ownership over a part of the product that they're building out of fear that they might leave.
- Not giving raises until it's too late; seriously undervaluing the long-term acquired knowledge of their engineers.
- Self-organizing and Self-directed employees are often the hardest to find.
- The HR process, when done correctly, allows individuals to join a group to realize their potential that they may not have elsewhere.
- The group's goals would have to be somehow set. I recall Clay Shirky's excellent essay on how a group is it's own worst enemy and can't help but wonder how it might play out in an environment like this.
Now, let's wait till WebExtensions API reaches feature parity with the old plugins. Vim addons are not yet able to open links in new tabs.
But Firefox is my favorite browser again.
I tried a bunch of other lisps but disliked them for various reasons. Clojure is nice because of the tooling, but I disliked being tied to the JVM and all what that means.
CL has some very nice implementations (Allegro CL has a limited free version that has forever changed how I think a programming environment should be).
In the end I found guile scheme which is great. The threading situation is good and getting better, the language has all the comfortable srfi's that implementations like chez lack, and it has nice community.
The reason I chose guile over chicken was the r6rs compatibility, which made supporting both chez and guile rather easy. Other than that, I'd say that the chicken community is probably the nicest one online. Chicken is really a fine scheme as well.
I am not a programmer though, and what I want is for programming to be just fun. Not enterprise ready, not web6.0-cool. just fun.
Shameless self-plug: I just finished my racket-like for l-loops for guile: https://bitbucket.org/bjoli/guile-for-loops
I also spend some time with clojure around the time of v1.0-1.2 and quite liked it, but it's maturity level and the JVM made it less attractive in the long run.
I like scheme as well, but because of the spartan(to use a nice word) spec, If I actually want to get stuff done I'd have to chose just one implementation and it's associated libraries, rather than rely on portable code.
Simple, strongly typed, and really really easy to write and read.
On top of that, its fairly easy to compile as well, which gets rid of a bunch of distribution problems that come with other Lisps.
My first in-production experience was converting a monolithic Python web app to Scheme.
We wrote a library that brought a lot of Python conventions over to make things easier. Like an import macro that automatically namespaces things. (And we copied Clojure's "->)" macro for closing all open parentheses).
Total conversion for ~18,000 LOC Python to ~7,000 LOC Scheme took about nine weeks. The speed-up was about 2.5x.
And despite the much smaller codebase for Scheme - we actually added a whole heap of features, whilst matching all old features. (A bug or two as well, but that's to be expected).
Scheme is just really well suited to parsing, and rewriting itself as necessary.
So far as I'm aware, that stack is still running three years later, so Scheme wasn't just a fad for the team (who picked it up in about a week or so).
Common Lisp is well-optimized for application programming. It has excellent compilers, and good debugging support.
TXR Lisp is geared toward scripting; it is a very agile, ergonomic Lisp dialect. It has minimal dependencies and builds as a single executable with some satellite library files in your /usr/share tree, yet is loaded with features.
TXR Lisp is a Lisp-2, but thanks to a square bracket notation, the coder can seamlessly shift into Lisp-1 style programming with higher order functions. Though it has the equivalent of CL's funcall function and function operator, they are almost never used, and there is no #' (hash quote) notation at all.
I am currently working on the aarch64 (64 bit ARM) port of TXR which I hope to be able to include in version 184.
I started the TXR project around this time of year in 2009, which makes it 8 years old now.
Handbook of Neuroevolution Through Erlang by Gene Sher makes a compelling argument (with detailed, varied examples) that Erlang is the perfect language with which to implement neural nets.
Lisp has always been associated with AI, of course. Nowadays it's all Python, Java and R for machine learning, but Lisp can do just as well, plus more: Lisp has an affinity for recursion, and its homoiconicity will - I suspect - prove fundamental for true AI. One can't just 'strap on' its features to those other languages (including Elixir: https://news.ycombinator.com/item?id=7623991).
So, obviously the right tool for the job is LFE!
I'm very happy with Guile and its performance has greatly been improved with version 2.2 (not that performance was a problem before); one thing I miss in Guile is the picture language that Racket comes with.
The ecosystem is great. I wouldn't use it for anything big on prod though, but it's easy to experiment with and is fun.
For over a decade I wrote mainly in C++ doing a lot of Windows programming, usually games or simulations. Mix in some VB and C# when I didn't want to battle the Win32 API. I was used to seeing codebases with 100k+ loc and hundreds of megabytes of code files. xkcd COMPILING is real!
While working at BitTorrent in 2013, a coworker back introduced me to his little server that distributes uTorrent executable to everybody. It was an implementation of this paper for a general purpose rules-based engine with a snappy (Clojurescript?) front-end. The whole thing was ~5k loc, and ran on surprisingly small hardware compared to it's traffic.
From there I was hooked. My project sizes are radically smaller, it's LISP, and I can go wherever Java goes. I wrote about my experiences with AWS Lambdas last year , for example. The community itself is outstanding. They are some of the nicest people you will ever meet. Because the community focuses on small libraries that are composable, those libraries become remarkably stable. Several heavily used libraries haven't had commits in months or years.
You can argue Clisp is easier to get a quick project going with, but short of that rather old project nothing with a setup any less capable than "lein new" is going to compare for dashing something out real quick.
Reality is that companies that are not desperate will be picky, take their time, drag you through a bunch of bullshit interviews, etc. Just like every other developer I get pestered by recruiters on regular basis and I often see identical job descriptions that I saw two years ago, so after short interrogation of the recruiter it becomes obvious that those are the kind of companies that are forever looking and never really giving anyone a chance.
I suppose my advice would be: start with the desperate ones, build up your experience and credibility that way and climb higher.
I had connected with this young startup through my budding network. I was young, they were young, and we were both involved in TeensInTech (formerly a community of teens interested in startups). I had done a couple rounds of UI/UX feedback for them, that they had requested via TinT. The company made a password & bookmark manager (not one of the ones that is available today. They want out of business).
One day they launched a major website overhaul. Excitedly, I went to their website to play around with it. Purely by chance, I fat fingered my password as I was entering it in. The login failed, obviously, but I was surprised to see that the password input on the failed login page was now filled with a mysterious looking hash. My assumption was that was my hashed password.
I sent them an email explaining the issue. Their website was promptly taken offline, hardened, and then I received a job offer.
tl;dr; I hacked my first employer's website, and they offered me a job for it.
It basically skyrocketed from there to what you can see in https://francisco.io/resume/ , with basically all experiences afterwards building on top of that (either directly, by reference or just as credentials for the next ones). People (including Google) also seem to love https://picnicss.com/ and I normally use it for showing my front-end skills.
Something I found surprising is that I got a really high quality contacts from my public projects. I would say about 50% of the job offers I get through my developer persona are high quality which I consider (even if many don't work in the end) vs what I used to get through Linkedin or even Facebook (both closed now) which were exactly 100% low quality/SPAM.
Software hiring is stupidly broken. Google has done much research on hiring and a code sample+cognitive ability are the two most important predictors of job performance.
Tell that to anyone that hired me ever.... The first time you'll even talk to another dev is your on-site.
When I was in charge of hiring once we made a huge deal of user repos and probably spent more time looking at them than resumes. Got some damn good engineers from that. But almost nobody does it that way
I'm involved in interview processes and hiring decisions at my current company - and rest assured that any code versioning accounts will be checked out.
Getting a job in that sector was as simple as having some general development experience and being moderately familiar with the platform.
It helped me get my first job at OpenedHand, working on free and open source software full time. I didn't have any previous experience nor a degree in CS.
After a few long discussions technically of Wordpress development they deemed me capable enough to handle the workload. I persisted with my intentions to help and break into web development, and it blossomed wildly from there.
By the time I started my second job, I had a real portfolio of Fortune 500 brands live and in the flesh and never looked back from there.
Honestly, it was stupid how easy it was to break into this niche. It took a lot of sleepless nights and long work weeks, but seriously anyone could do this. I'm a big proponent of that. I was a meat cutter before this.
- I found AngularJS a few weeks before AngularJS 1.0 came out in 2012. I started using it for pet projects and became a serial user and answerer on the AngularJS google group for a few months. I spent 1-2 hours every day answering questions.
- A few people from that group started a library making AngularJS UI components for Bootstrap CSS, and I helped: https://angular-ui.github.io/bootstrap/. This was what really got me "slightly known" in open source.
- I moved on to making other AngularJS libraries: most known were angular-promise-tracker and angular-mobile-nav (slide transitions for mobile AngularJS apps). And then eventually, because of my experience, I landed my first job on the Ionic Framework team.
I quickly moved up to consultant (since I was with a consulting firm) within a year and ended up getting some real experience on my resume. :-)
I imagine that in time, someone will look at that code and use it as a consideration for his employment and be just as disappointed in his output as I was. You may hate it but I love white-boarding with candidates. It's not a binary pass/fail exercise but a look into how a person approaches solving a problem and handling on-the-spot pressure. Sometimes things break in prod and the pressure is on, I want to work people that do well under that pressure.
Landed me a job in a small game studio. I'll never understand.
One of my users said "Anyone who can write a BBS for a Vic-20 can program!" and hired me to write code for MSI portable data terminals. That same guy now wants me to work with him at Google.
A Dark Age of Camelot (MMORPG) chat log file analyzer written in Perl in 2003-2005 helped me land my first dev job.
I switched careers (due to lack of job openings) from becoming a protestant pastor to being a full time developer. I had almost no proof of having programmed in Perl for close to 6 years as a hobby, but the company desperately needed another coder and their senior programmer at that time had taken a look at my SF page. The boss was impressed when I said that my code had been downloaded by over a 1000 users, and so I got my first job, rewriting an SMS-messaging platform.
Now, over 10 years later, my GitHub profile only rarely comes up when recruiters try to reach me - some, I think, use web scraping to match profiles with LinkedIn / Xing to say nice things as a conversation starter in generic emails.
A PHP endpoint that received a POST request of some sort, and then I would return something based on that, a very primitive REST service and a C# application would act accordingly, and it would log the data to a MySQL database. It was meant to allow us at my old job to keep track of who used our computer lab, it wasn't meant to be overly secure on the front-end, if they figure out how to break behind the application we weren't worried about those cases, only the case where our database was compromised.
I think the more important bits of my interview were just our overall conversation, the code just showed I wasn't all talk really. He liked the answers I gave and the rest is history. That was 1 year and 1 day ago. Still working at my "first real job" as most people call it. My previous job was part time and at a school so I didn't do many programming projects.
A year later my app got removed from the store because "it did not comply with their policies or terms of service".
A few weeks after exams ended, and a few months before I would graduate with my Bachelor of Commerce degree (Finance Specialist), I went to my first interview for a developer position at my University. After talking with the manager/team-lead, I was handed a page of 12 questions ranging from logic, sorting, jQuery and databases, and given 30 minutes to complete them. I aced most of it (hiccuped on the sorting). Got the job. Made this: http://m.map.utoronto.ca (just the mobile version, which was a ground-up rewrite SPA)
Been 5 years now. Have worked on projects for Facebook and Google (although not employed by them, but via agency vendors), went through Intermediate Developer, Developer, Senior Developer, now an Architect at a cancer research place.
Still no portfolio (never got around to it), but here's my Github: http://github.com/cheapsteak/
That (and a few other factors) got me a role at Headquarters, on a networking team. But I kept writing tools in software and ended up getting snaffled for a web-development team. And have been doing web-applications ever since.
So to answer your question I guess, it depends on your area of expertise. It's easier in my opinion if you're a front-end guy because you'll have "something to show". If you're a backend developer you can always cook up a library in whatever language you use and share it with the community, that along with a blog can go a long way in helping you landing a job.
Hope this helps
The next job I just applied and did exceptionally well on the interview. The one after that was through a friend that I worked with before, he was starting a company and hired me.
I just started working on a simple Django cms called Amy and that has also gotte me work. Weird.
See Amy live at yelluw.com (https incoming!)
Technically I had one other dev job before that (not in games, making websites and apps in ASP and VBA), although I got that job from a friend who knew I could code due to indie game dev meetups, convinced me to move upstate to the Chicago suburbs and be his roommate, then bugged his boss until he hired me. I barely knew him, but it ended up being a good decision because I ended up really fitting in here and I'm still in the area 12 years later.
This project is closer to my heart and I would still be happy if I had not gotten a job because of this.
The repository that taught me about parsers, code style, and algorithms was writing PrettyDiff.
I did a code challenge as application, so I believe this was the most important code. But this is my portfolio page (untouched since I got the job): http://rodrigo-pontes.glitch.me
I believe the most important project in it was this To Do app because it shows I can ship things that work:
Highlighted some insights based on the way Tweets were made. Got an offer from one of those brands' Data Science team and finally found out that my Analysis became benchmark in the company for Social Media Analytics of Twitter.
Edit: Though the job wasn't my first one!
very short video: https://i.imgur.com/4zDAQe7.mp4
Was hoping to publish this app but could not find an appropriate service provider for the images.
Mostly people contact me for web scraping and automation related work after viewing my site or blog posts
 - http://adnansiddiqi.me - http://blog.adnansiddiqi.me/tag/scraping
It showed I could create a proper project which follows best practices like CI ect. It also helped that it was pretty relevant to the type of business and something that they themselves could potentially find useful.
This was for a junior full stack dev position in SF
It was the only interview I've ever had where someone actually did that.
Somebody drove me home when I attended a local event, and a few years later, that person hired me (and is now my direct supervisor).
I had done a few website before, but nothing significant.
I think it does not matter what's in your portfolio as long as you've released a few things and did everything to make to them look good. Not necessarily design but presentation, documentation, testing and function.
I'd grown up futzing with code in the 80's (AppleBASIC, a bit of assembler). Turbo Pascal, ANSI C, in the early 90's. I'd started crunching through Ivor Horton's book on Visual C++ in 2000.
My girlfriend's (now my wife's) employer had an ecommerce website that was written in this thing called PHP and it kept throwing errors, something about MySQL. Figure out it was hosted on this "Apache" thing.
Bought a SAM's Teach Yourself in 24 Hours on LAMP, spent a month digesting it, fixing the issues with the site in the meantime. When I was done with the book I wrote my own ecommerce platform to replace the one they had (I did all this for no compensation, I just wanted to learn).
Took programming gigs off of what was then called "rentacoder.com" working for almost nothing to get experience and built a portfolio.
The next year, 2004, a big auto parts company in town was looking for a "webmaster." I leveraged having built an ecommerce platform from scratch into that job. I was all things internet for them (except graphic design). Wrote code for their ecomm website (old school ASP.NET), did SEO/PPC marketing, came up with email campaigns, integrated with their ancient PICK-based inventory system, used NLP to detect tone in customer support emails before that was something you could farm out to Google, etc.
So...the replicable aspects of that path, excepting luck and right place right time:
1) Dive deeply into a challenging language. C++ wasn't for the faint of heart then and although it's been years since I wrote any I'm sure that hasn't changed. I'm a much better coder for having had to deal with the obtuseness of C++. Pointer pointers, anyone?
2) Do work until your skillset and portfolio represents enough value to someone that they're willing to pay for it. So much of my early work was garbage anyway...hell my SAMS book on LAMP hadn't covered SQL JOINs, so I was doing queries and iterating through the results and running more queries!
3) Build something that non-developer can understand and connect to. I was able to talk about the ecommerce site I'd built, how I'd integrated with PayPal, demonstrate the UI, etc, to the people that hired me. Had I been presenting something more esoteric, like the time I had to figure out endianness to decode a data file and get it into a MySQL database, I'd have completely lost them and likely not have gotten the job.
Put together working projects and deploy them, make it easy for someone to see what you've built. Provide evidence that you are capable of working with external APIs and common frameworks.
I am self taught and landed my first job pretty easy with just a basic portfolio site, and a few FreeCodeCamp projects that were deployed on digital ocean.
I am now involved in hiring with my company and very rarely do I see an impressive repo let alone an active github, but whenever I see someone consistently committing they always end up with an interview and more often than not end up with a position.
Cmon guys, a US Masters for 7000 USD? Are you kidding me? Its totally worth it. In fact I feel blessed that such a thing even exists. GaTech has been a trailblazer in this regards.
My wife did an online master's degree (at a legit university that also had an online program). You have to be very good at self-pacing, diligence, and learning autonomously. You have to be so good at it, in fact, that the type of person who would succeed in an online master's program is the same type of person who would succeed in self-learning without the master's program.
So if your only goal is to learn, then I say no, it's not worth it.
However, you're in Brazil and not a lifelong programmer. Credentials may work against you if seeking a job in the US. Many US companies look at South America as the "nearshore" talent, much better in quality than devfarms in India, but also still cheaper and -- because of that -- slightly lower in quality than US talent.
In that case, spending $7k and completing the program and getting the degree may help you get a $7k higher salary in your first (or next) job. It may give US companies more confidence in your abilities, as you received a US graduate school education.
So from a financial perspective and the perspective of job opportunities inside the US as a foreigner, then I think it may be worth it. If you don't care about getting US jobs then still probably not worth it.
Best of luck!
Honestly I think your time is better spent working on real projects. In my CS master's program I met many students with no real-world experience. One was a paralegal before school, and after he graduated he became...a paralegal with a CS master's. Experience > degrees, every time.
There's value in the program (algorithms and data structures being the most applicable), but just go in with your eyes open knowing that the degree is not a glass slipper that'll turn you into Cinderella overnight. Too many IMHO falsely believed my program was a jobs program and really struggled to find work in the field.
If you can do it at night while working FT, great but don't take 1-2 years off work. It sounds appealing to be done ASAP but you're unlikely to make up that 60-120K/year in lost wages. Unless you're fabulously wealthy.
Got a job at Google directly because of this program (a few classes like CCA helped a lot with interviews). I'm aware of at least a couple dozen of us from OMS here.
The program cost me dearly. It cost me my relationship with the SO and it cost me my health (staying up late nights, lots of coffee).
* $5k cheap, it's nothing, the real way you pay for it is via your time.
* The teachers like the flexibility as much as we do. Many are top notch. I took two classes from professors that work at Google (Dr. Starner and Dr. Essa), one at Netflix (Dr. Lebanon), and a few others have their own startups.
* One of the classes was taught by Sebastian Thrun, with a TA at Google, but I think that's changed now.
* The lectures are good, but you have infinite ability to subsidize them with Udacity, Coursera etc.
* You learn squat by watching videos. The true learning happens at 2am when you are trying to implement something, and end up tinkering, debugging, etc. That's when things click.
* The hidden gem is Piazza and some of the amazing classmates that help you out. Lots of classmates that work in industry and can explain things a lot better. I.e: Actual data scientists and CTOs of Data Science companies taking the data science class. They were amazing and I owe my degree to them in part.
* Working full time and taking classes is not easy. Consider quitting and doing it peacefully.
* From within Google, I've heard from people that did the Stanford SCPD (I'm considering it) and also OMSCS. Lots of people that say the SCPD program wasn't worth the time and effort. No one yet that's said the same about the GT program.
I've heard from people that have done the program in-person, and they say the online lectures and materials are significantly better.
A couple of things to consider: As you mentioned, it is more focused on Computer Science than Software Engineering/Development. There are a couple of Software Engineering/Architecture/Testing courses but I haven't taken them so I can't comment on how relevant I think they are to my day job.
It's an incredible bargain... 7-8K for an MS (not an online MS) from a top 10 school in CS. That on it's own makes it worth it for me.
It's not easy and it's not like a typical Coursera/Udacity course. Depending on which courses you take it can be quite challenging (which is a good thing). You typically don't have much interaction with the Professors but there are a lot of TAs and other students to help you along the way.
Here's a reddit in case you haven't come across it that answers many questions:
And here's an awesome course review site that a student built:
(Source: current OMSCS student, hopefully graduating in December)
I made an "informed decision tree" awhile back that goes into much more detail about my thought process when signing up for this degree:
I also reviewed the OMSCS program in detail here: https://forrestbrazeal.com/2017/05/08/omscs-a-working-profes...
Hope that helps!
Did I learn a lot?
I learnt a ridiculous amount. For the time+dollar investment it is amazing. The program is definitely not easy either.
It has been amazing to learn the concepts in ML (Dr. Isbell) and AI (Dr Starner) courses and then a few weeks later think "I think I can actually use these concepts in my workplace".
Why the mixed feelings?
Not all courses had the same quality to it. From the top of my head, AI, ML were probably the best 2 courses. Other well ran courses I would add was computational photography, edutech, introduction to infosec (besides the rote learning...), however some of the other courses I had a relatively negative experience.
The degree does suck up a lot of time and I would say it is the real deal.
Knowing what I know now I can't say 100% that I will "re-do" OMSCS - to be fair on GaTech I'm not sure whether the challenges that I feel above are due to an online program and I personally would be more suited to an in-person program but the experience has definitely been better than Udacity's nanodegree and any MOOC which I have sat.
Overall I would say if you do it for the sake of learning and that alone - OMSCS is worth it. For any other reason please don't do it.
The program does have its hiccups here and there. Some courses have been reported as being poorly organized, but this is certainly the minority. Also, you may not receive as much individual attention as you would in a on-campus program. This is aided by the fantastic community of students in the OMSCS program which provide a support system for each other through online forums/chat. If you are not much of a self-starter and need specific guidance, this program may not be for you.
One thing I'd warn though is that you'll get out of the program what you put into it - so it's really up to you to choose classes that will set up your career the way that you want it.
I'm about halfway through and many of the classes assume that you have the equivalent of an undergrad CS degree. It's not intended to replace an undergrad degree.
That doesn't mean you can't do it, but your going to spend a lot of time catching up. From what I've seen, the students without a CS degree, even those with significant industry experience, have had a much harder time with the more theoretical classes.
It's also a graduate program, and the classes are pretty rigorous compared to what I did in my undergrad CS degree.
Also keep in mind that admission is fairly competitive. And admission is only probationary. You have to complete 2 foundational classes with a B to be fully accepted.
Here are my thoughts on what people need to succeed as an OMCS student:
* Be able to program in C, C++, Python and Java at an intermediate level. And, know one of these very well. * Be able to use a debugger (GDB) and valgrind. * Be able to administer and configure Linux systems. * Understand data structures and examples (std::set in C++ is RB Tree backed, std::unordered_set is hash table backed) * Understand basic networking concepts and key technologies (TCP, UDP, IP, switching, routing, etc.). * Understand the x86 computer in general.
I've done well so far, but I have the programming/logic background to do the work. If you don't, brush up on the skills listed above before enrolling.
Edit: The class projects are a lot of work. Be prepared to give-up your weekends and evenings. Even if you know the material and the language, it's a job to get through some of the projects.
It's hard for me to estimate how much prep I would need to do to come in to this program and feel comfortable with the tasks at hand.
Cons: I've noticed some students who come to get their MS degree from a reputed institution because it is cheap. Due to coursework pressure, they take short-cuts, like doing group-work, discussing solutions when you are prohibited, plagiarizing in assignments, etc.
1 - The people I've seen doing it are learning A LOT - more than another online program I've seen.
2 - They're also working A LOT - it intrudes on all aspects of their personal life. It's as much or more work than doing an in person CS degree.
3 - The folks I know don't have CS undergrads, which also makes it more difficult.
Net - it can be worth it if you missed CS as an undergrad, but you'll have to work. You need to ask if there are enough people in Brazil who value the credential (or implied skills) to make it worth the time. The time investment is more expensive than the $s. (It will be thousands of hours)
Would anyone who works full time and gone through this program care to share their thoughts?
Edit: Just found this great article from another comment
The classes are cheap. The hours are long. In the end your grade depends on teammates who haven't been vetted. Three teammates who can't code? You get a C and don't pass.
Course content is extremely dated. UML and SDLC paradigms from the 70's with xerox pdfs distributed to "learn" from.
This is a money grab.
Otherwise, I think OMSCS is totally worth it. It is hard though. Really hard. I have a family, significant engineering experience, and I find the workload intense. It puts pressure on my family at the same time because I'm not available as much. So I'm taking it very slow, no more than 2-3 courses a year.
It feels great to be 'back at school' after so many years. I love learning new stuff and the challenges of hacking away at low level things. The kind of thing you rarely get to do professionally unless you're very lucky (or not getting paid much). Almost makes me wish I had done a Ph.D.
I don't know if it will help me get a better job or whatever, but it definitely fulfills my own internal itch.
I'm through my second OMSCS semester, and it you want to know if I think it's worth it...you'll have to read the post ;)
I don't know how it would be looked at in Brazil or what the economic cost/benefit are in terms of your own income. I did know a few folks from the University of Sao Paulo that did grad and postdoc work while I was at GT though, so clearly some people are aware of GT in Brazil. That might be another avenue to get opinions from. I would be interested to hear how the costs compare to an institution that was local to you.
edit: Answered my own question - You can't have two consecutive semesters "off". I.e. the slowest possible pace would be 2 classes in the first year, then 1 class every other semester. So I suppose it would be:spring/summer 'xx: 6 credits, 24 remaining, spring 'xx + 1: 9 credits, fall 'xx +1 : 12 creditsetc.
 - per https://www.reddit.com/r/OMSCS/wiki/index
I don't think it will have an immediate impact on my earnings or place in my company, but I think the long term value of having it far exceeds what I'm paying for it.
Folks say institution-X is the same. I haven't seen one. Princeton or Stanford are, AFAICT, stunningly more expensive, and not purely remote.
This is a "sine qua non" - without this particular option, there is nothing else on the menu for me at this point in my life and career.
However, computer science and software development are not the same thing. If your primary goal is to up your game as a software developer, you might get more out of well-regarded software development books like "The Pragmatic Programmer," "Working Effectively with Legacy Code", or "Design Patterns."
Hope this helps.
If you work for a reputable company, like I do, they do tuition reimbursement. My company just so happens to cover $5200 per year.
So inother words, I am getting the degree completely for free.
I have completed 7 classes so far, and have 3 left, which again, were all paid for.
The classes take a lot of time (see https://omscentral.com), but the learning has been a lot of fun. I loved it.
Does anyone have insight if doing Georgia Tech's - Master of Science in Analytics will help me land such role?
First and most important: your internships and work experience, and what you accomplished during those jobs. They should tell a story of increasing and accelerating personal growth, learning, challenge and passion. If you can share personal or class projects, even better.
After your experiences, your degrees will be considered based on the number of years each typically requires, with early graduation and multiple majors being notable.
1. PhD, if you have one. A STEM PhD was particularly helpful for ML/Data science positions, but not required. 2. BS/BA (3-4 year degree) 3. MS/MEng (1-2 year degree)
International students get a raw deal. The online masters will barely help you get a job or launch a career in the US. US universities appear to offer the chance to work for major US companies with a notable university (such as Georgia Tech) on your resume, only to feed their graduates into our broken immigration and work authorization system, H1-B indentured servitude and no replies from the countless companies that have an unspoken higher bar for those needing sponsorship.
To round out a few other contexts HN readers might experience:
If you are an international considering an on-campus MS/MEng, US universities are charging full price while giving you a credential of limited value and utility. Apply the same comments above but at a much higher price than GA Techs OMSCS.
If you are completing/just completed a less notable undergrad degree, paying for a masters program at an elite CS school (like GA Tech) is usually a bad deal. If it not a requirement for the positions you seek, it won't help your career chances much.
If you have an undergrad degree and your employer will pay/cover your MS/MEng at night/personal time (and that is your passion), awesome and go for it! It will be a lot of work and lost sleep to get everything out of the experience, but a lifelong investment in your growth and experience.
If you are completing/just completed a notable undergrad degree (tier-1, internationally recognized program), you don't need the masters. Feel free to get one for your learning, sense of self and building research connections while you ponder getting a PhD. The hiring and salary benefit will be very small--you are already the candidate every company wants to meet. If you decide to get a PhD, that will open some new doors but take 5+ years to get there.
At my previous company, we made it our forte and team passion to get authorization for employees--given a global pool of candidates and a hiring bar to match. I'm really proud of our effort here given the broken and unfair system. Sadly, many companies do not share this value or cannot justify the time, effort and expense, or cannot scale such a program to a larger number of employees across a less selective bar.
That's something you could learn on your own. But your knowledge of "technologies" are more valuable to employers than CS degree - especially if you have work experience.
The tech industry isn't like academia ( economics ) where you have to build up credentials. Work on projects that deal with web technologies or even better learn the back end ( databases ) or even the middle tier/server code if you are a front-end developer.
Becoming a full-stack ( front-end, middle-tier and especially back-end ) is going to be far more important to employers than if you know what undecidability is or computational theory.
Degrees are very important if you want to break into the industry ( especially top tier corporations ). But if you are already work in the industry, employers want to see the technologies you are competent in.
If your employer is willing to pay for it and you have free time, then go for it. Learning is always a good thing. But if you want to further your career, go learn SQL ( any flavor ) and RDBMs technologies - SQL Server, Postgres, etc ( any you want but I recommend SQL Server Developer Edition if you are beginner on Windows OS as it is very beginner friendly from installation to client tools ).
A full-stack web developer is rare and you could even sell yourself as an architect/management. That's a difference from being a $60K web developer and a $200K full stack developer/architect.
Employers will ignore you the second they find out your master is not legit.
Ultimately, the answer to most "do I need a lawyer" questions is, yes, when the stakes are non-trivial.
This will very likely have tax implications as the IP has some value, and companies cannot (usually) just give away assets to an individual.
Once you own the IP, you can do (almost) anything you want with it, including start a VC-backed company.
Having a goal around your actions is somewhat implied here.
So what can help us cultivate discipline? Well, each time you practice discipline you are cultivating it. So what can help us practice it?
1. Mindfulness; whether through meditation or other practices, practicing mindfulness can help you gain some distance from your thoughts and feelings and make a more reasoned choice to act towards your goals.
2. Environment; setting things up to make taking action easier (e.g. putting you shoes by your bed if you want to go running), or making things harder to do (throwing out all your junk food, not shopping when hungry)
3. Having compassion for yourself. You will never achieve perfect discipline. Realizing that you will screw up, especially in the beginning, and having compassion for yourself when you do (as you might have towards a friend who is struggling) makes it more likely that you will continue to cultivate discipline.
There is a good podcast that covers a lot of this that I think is well worth a listen. Don't let the title of it dissuade you; it is much more than just about depression and procrastination:http://www.myownworstenemy.org/podcast/why-procrastination-m...
Example: I've been going to the gym for a few years now. I don't have the best consistency for going, since I normally go after work hours. I found that by the time I was done with work I was tired and feeling burnt out from the day, and it was easy to skip going. I started making myself go first thing in the morning by waking up an hour early than normal and so far its working.
gcheong's comment about environment is also spot on. Make it easier for yourself to stay disciplined. Reduce the amount of willpower/effort that it will take to start a task.
That's what got me in the habit of budgeting/expense tracking and quitting caffeine.
It's literally a bunch of bash scripts so it's as straightforward as it gets to understand how it works. As a simple deploy target for side projects it works great.
I pay for code reviews in the UK from a company called Atlas Computer Systems Ltd https://www.atlascode.com/
They do code reviews for startups to make sure your code is high quality and isn't building technical debt.
So, yes, "it costs too much" is the obvious answer, but it is true. Unless the recipient is in the same "zone" as the shipper, the cost of next-day air shipping is likely still anywhere between $20 and $50 (dependent on many factors), which is heavily discounted from retail rates. That would cut into margins quite a bit.
Second time: 5 months
I am coming up to the end of my personal runway on this current venture but I raised some money from friends and family and I'm able to pay myself a little bit now! Meanwhile I know people who are sitting on 4,5,6 years of runway and are still just talking about doing it. Whatever it is, if it excites you and you can convince others of that, go do it today!
I'd suggest about 6 months of runway to be safe, but we aren't doing this to be safe are we?
Market validation in 1 month, very strong traction with no marketing. Spent 6 months trying to find investors.
Started borrowing lots of money to keep it afloat. It had good revenue but not a profit (e-commerce profit margins were around 6%). Couldn't get investors despite two accelerators, so we sold off the company after 14 months. But we made a good profit even after paying off debts.
Second time: years(?)
Ended up trying to do too many features. Still "wasn't ready for launch" 9 months in, ended up building features with no market validation. I ended up quitting the company because no progress was being made.
First and second startups were essentially the same, except the second one had a much bigger team, more ambitious.
I'd say keep your runway as short as possible and try to launch something by 3 months.
Although if I were giving advice to someone else doing a startup where it's difficult to get immediate traction (e.g. hard tech, enterprise SaaS, hardware, etc.), I'd remind them of the Jason Lemkin rule that it typically takes 24 months to get anywhere.
i am proud of it, but i don't think it is startup, maybe just a side project.
Btw, that was personal runway - i.e. didn't get paid for that period. Rather than raising 12-months of getting paid.
In your cliche NET 2.x MS-only Windows-Only enterprise setting they won't look down on it, but they might feel you don't have relevant experience.
In many other places people value developers that have non-mainstream development experience because it shows you're willing to explore as a developer and won't shackle yourself to one solution to problems the business faces.
I do have a lot of money in stocks and with those I don't do nearly as well but clearly I learned enough to make a quid or two in crypto markets.
It is really easy to get started (just sell stuff that you can find in your house and don't need anymore) and I really like this treasure hunt feeling when entering a thrift store or looking for clearance.
made me so far around 300 in less than 30 days and still have inventory left for about 150. and I'm still learning what might sell and what not.
Link to my latest project - https://github.com/DrRoach/DynamicImage (It's a dynamic image generation library if you're interested)
~ $30/month from donations covers my Digital Ocean bill for the month.
I'm also trying to get some sales & affiliate revenue going with athletic wear designs on Zazzle. Starting with a niche to get rolling then probably expanding to more general designs. The biggest problem I've hit so far is their fulfillment times & prices.
Yesterday I have launched https://submit-sitemap.com and I have shared link to it on various platforms. How much traffic I got:
- reddit - side project - 4
- hacker news - 11 (+2 from different aggregators)
- I have added link into 2 communities on Google+ with around 200k people - 3
- producthunt - 3
- Facebook where I have shared it in group with 5k people - 5
- StumbleUpon - 1
And I think that I can subtract 1 from these numbers since I have clicked on them myself to test if those links works. :)
Makes me zero money and some knowledge.
Started charging this month.
~ $40 / mo
Is the term "hustle" not extremely negative to you?
Merriam-Webster defines "hustle" as to push or shove someone in a rude way.
Urban Dictionary says "Anythin you need to do to make money... be it sellin cars, drugs, ya body. If you makin money, you hustlin."
Obviously, you don't seem to think that the word "hustle" has negative connotations, so I'm wondering how you came to that view?
There is a free course on edx Analyzing and Visualizing Data with Power BI https://www.edx.org/course/analyzing-visualizing-data-power-...
- find a (cheap) alternative to Tableau for data viz
- allow basic self-service analytics for your team
- embed charts into applications
- provide a professional growth platform for data engineers
It sounds a bit like you're trying to build what the folks at Clearbit covered in a blog post:
Some suggestions (a few of these tools have been mentioned already):
- AirBnB's Superset http://airbnb.io/projects/superset/
those two are open source products; not that the PM on superset used to work at Tableau... just sayin'...
for data viz & embedding charts:
- Mode Analytics
- Periscope Data
- reflect.io (highly recommended, built just for that purpose, but I think they want $60K / year too...)
shoot me a note at lars at intermix dot io - we have a spreadsheet with all the data viz tools out there, a list of some 40+ tools....
- Designed with the analysts who's comfortable with SQL in mind, thus extremely flexible.
- Extra visualizations catered for product/marketing analytics: Conversion Funnel, Cohort Retention
- We have in-built ETL that helps analysts load data from Excel, CSV, Google Sheets to your reporting DB without bugging engineers
They have different licensing prices for the different types of users. For example, the web consumers, that use the templates created by others, are much cheaper than the the full analytics license. Scripting in IronPython, custom visualizations in d3.js and .net extensions. Custom data sources in .net.
Not privy to prices but I would be surprised if it's less expensive than tableau.
So for me having a competitive element to what i consider a fairly boring job definitely makes it much less boring. As for rudeness and arrogance I try not to be those things but if somebody else is i just ignore it. Simple as.
Developers who are not team players do not make it far in my experience.
It's sort of like religion. My IDE is better than yours, my tech stack is better, and you're just ignorant for not being enlightened.
I don't think there is a solution to the arrogance. One of the root causes is that everyone thinks they're hackers who found a better solution. The other cause is that they've invested a lot into what they learned, so they don't like it when better tools obsolete that.
I've often reflected on where this arrogance comes from. My personal theory is that a lot of people, when they show an ability to work with computers, get a lot of positive attention from those around them because most people don't have the patience or inclination to understand machines so well. I think for some this leads them down the path of really building their identity around what they can do. And when you deeply identify with something like that, it becomes very personal.
This isn't true of everyone, you can have passion without being arrogant, but it is quite common I believe.
Another factor is probably the perceived competition for jobs and promotions. Many think that to reach the next level, or get the six figure salary, they have to out compete others. And this is true, to a point, as the technical coding interview shows.
Edit; something related is the 'tribalism' around languages and frameworks, frontend vs backend, os's etc. When you're just starting out, it's easy to become invested in whatever technology you learned first. You'll write a lot of code and become really accustomed to the tools, libraries, building and deploying. It's only when people branch out and spend a lot of time with other languages and frameworks do they start to see the commonality between them. There's been a lot of convergent evolution over recent years imo. I find that people who understand the basics (http request/response for example) are much more adept at debugging, trouble shooting, and jumping between languages and frameworks.
"I think we should focus on the positives." - says guy who talks the most shit.
For instance, there are some people who only use Microsoft tools since they have an MSDN subscription.
There are other people who run Linux and use only open source tools.
Frequently people in those community think the other one "sucks", even though they both get their jobs done.
To answer your question, I'd write a fantasy economic sim game like a sequel to Patrician III or something, except with wizards and weird races and stuff. A big bit of the game would be negotiating with customers for custom goods and services.
Exactly how much money would it cost to for a casting of Bull's Strength before a mercenary engagement? What are the obligations a wizard has in the event their town gets attacked? When is the Teleport spell economically viable vs just taking a boat? How do you negotiate with beings very alien to you?
Classic pet project that I've wanted to do for years, just never had the time/concentration to do it.
If I could be bothered, I would write a really detailed political simulator a la Democracy but with much more detail and elections.
Sure, it may be possible to get things working smoothly today, but that doesn't mean that all the areas I mentioned (documentation, etc.) have caught up. The primary reason they don't catch up is the straggler libraries keep many teams in a past era.
Right now, the state-of-the-art is exciting but falls short in some world-changing areas like question-answering. As much as I want to, though, I have no idea how to push the field forward, however.
For the other things I want to do, I am probably sufficiently skilled to do, but I just need the time and motivation.
A content-first web browser (think Reader-Mode for every page), depends on: a) Learning the differences between the HTTP|HTML|CSS|JS specs, and what browsers actually implement, and b) heuristically lifting out the content.
b) is a programming problem, not easy to solve well, but there's been a lot of work in that area to lean on.
a) is a documentation/people problem. Not my area of expertise, but definitely the harder problem of the two.
But then I grew tired of waiting and just did it already :)
The ORDER of we are learning Rust
It's less useful to explain about language capabilities by examples or explain about lifetimes before structs, enums
Installation & Hello World Cargo & Crates Variable bindings , Constants & Statics Comments Functions Primitive Data Types Operators Control Flows
Vectors Structs Enums Generics Impls & Traits
Ownership Borrowing Lifetimes & Lifetime Elision
Modules Crates Workspaces Error Handling
Functional programming in Rust
1. Don't build OO abstractions, just use structs as data and operate on it with free functions.
2. Don't be afraid of long argument lists with lots of references, where the last one is possibly mutable, C-style
3. If something needs e.g. 2 different structs as inputs and mutates a third one, make it a free function, don't impl it on any of the structs.
4. Don't overdo it trying to use the functional idioms for options and results like and_then or_else etc. Just use match and eventually it will be obvious where those fit.
5. Don't worry too much about error handling, just use expect and explicit panics
6. Don't implement your own data structures, compose the std lib ones
7. Get good at using match and enums to represent state and transitions
Once you've got some more experience and you want to try to write more elegant code, you will run into ownership issues.
1. Use guard types. Basically a struct that owns a pointer into some larger data. Write a lot of these with useful utilities for manipulating that data
2. Use guard types for mutating data as well. I tend to have a type which is a big bag of data (often carefully laid out in memory for performance), and then separate types whose only purpose is to contain references to e.g. 2 or 3 different pieces of data that need to be simultaneously used. That type allows you to do whatever that operation is. This saves a lot of borrow checker fighting.
3. Think in a data centric way. What data do you need? What operations need to be performed? Then design your ownership hierarchy such that that can happen.
Finally you will run into frustration structuring large projects.
1. Use cargo workspaces. Isolate self contained chunks of functionality into crates.
2. Implement stdlib traits like Iterator, From, Into
3. You can use associated types to do statically checked dependency injection. In combination with default trait implementations it's a decent way.
4. Use free functions liberally inside modules, but export mostly traits, data structs, and operation structs.
5. Use rustdoc comments in your code and refer to them.
A lot of the above is opinion and might not work for everyone. I submit that it's "a path" of many for getting productive quickly and then scaling up to writing larger systems.
(Crosspost of a comment I made on Reddit: https://www.reddit.com/r/rust/comments/6rxw21/comment/dlb048...)
Sometimes they don't have enough slots available, so there's a chance we might not get it. I'll give it a shot for you.
>"We have observed the following in our own recent direct experience investing in SAFE and convertible notes: that many founders have a tendency to associate the valuation cap on a note with the future floor for an equity round; that they further assume that any note discount implies the minimum premium for the next equity round; and that many founders dont do the basic dilution math associated with what happens to their personal ownership stakes when these notes actually convert into equity. By kicking the valuation can down the road, often multiple times, a hangover effect develops: Entrepreneurs who dont do the capitalization table math end up owning less of their companys equity than they thought they did. And when an equity round is inevitably priced, entrepreneurs dont like the founder dilution numbers at all. But they cant blame the VC, they cant blame the angels, so that means they can only blame oops!"
I believe she had her Chromebook for 4 or 5 years before it just died... and she ended up buying another one. Can't really complain.. 4-5 years for a laptop that is used everyday is pretty good. I tend tog o through 1 every 2-3 years. But love it for its speed.
It's the kind of thing I wish I had when I was in school, and I wonder if your students might find it helpful.
I'll shoot you an email!
Investing > Capitalization Table:https://wrdrd.github.io/docs/consulting/investing#capitaliza...
- I'll add something about Initial Coin Offerings (which are now legal in at least Delaware).
Lever ( https://www.lever.co ) makes recruiting and hiring (some parts of HR) really easy.
LinkedIn ( https://www.linkedin.com ) also has a large selection of qualified talent:https://smallbusiness.linkedin.com/hiring
... How much can you tell about a candidate from what they decide to write on themselves on the internet?
"Startup Incorporation Checklist: How to bootstrap a Delaware C-corp (or S-corp) with employee(s) in California"https://github.com/leonar15/startup-checklist
It's now installable with one conda command:``conda install -y notebook pandas qgrid``
Sales will throw money at anything with a clear ROI. If you can reliably say it'll make salespeople 1% more effective, then that's an easy decision. If you look at Chorus.ai / Gong.io / VoiceOps - these are new sales tools that have really burst into the market.
That said, as a result of this, there is a lot of tech in both of those domains. Your customers will have a lot of tech and be bombarded with a lot of options. Is is very noisy and confusing. So it gets harder to get above that noise and stand out. Particularly in the early days.
So even in those cases, I think starting out in a niche can make sense (A niche of startups can be a good one for a bunch of reasons). Simplifies your approach to the market.
Marketing budgets are huge, but the barrier to entry for creating another SaaS marketing tool is low.
If you yourself are looking to start a company, the easiest thing to do is figure out what advantages you have that other companies don't have.
If you have a proprietary advantage in a crowded market, then don't worry about the competition and focus on telling your story to your customers.
But I would avoid entering markets that have low barriers to entry and where you don't have a proprietary advantage, simply because you want to avoid markets with high barriers to entry.
Listen to your gut. If you see red flags, most likely there are tons. Either they are giving you a written contract/offer with the terms agreed verbally or they are not. There is no middle ground. There is no confusion. Be very clear about that.
About notice period, I cannot add anything being an American because we are used to "at will" employment where a 4 week notice is actually considered long. But good luck with that.
1. One part of the company isn't talking to the other. One person wrote the offer letter and another wrote the contract, or the contract is "standard" and hasn't been updated for your particular case.
2. The company is intentionally trying to get you to accept less now with vague, nonbinding promises to make up the difference later.
I would guess that the first is probably more accurate. Keep pushing to get the offer letter terms into your contract. You'll find out soon enough if they refuse.
This lack of communication might be a red flag on its own, of course.
IMHO the prevailing attitude in the UK is that the contract is a mere formality.
> My notice period, shall I want to leave is static at 3 months. I don't like this.
That is quite rare in my experience. I wouldn't be happy with that, personally.
P.S. I'm slightly biased in that I find overall contracts quite egregious these days (maybe on a global scale we in the UK used to have it good?): assigning of all IP past/present to employer, no other paid employment at all without their permission, submitting to their medical examinations/sharing of medical data, 10s of legalise terms that make it easy to fire you, e.g. to the effect of "you will give all your exclusive attention to the company", "never speak ill of the company"...
I was on a 1 month notice, and they let me go after 6 months for "performance" reasons. No mention of any performance issues in my 2 reviews prior, during my 3 month probation period. It was just after I completed the project I started on so I was just a cheap contractor (in hindsight, there where other signals).
To me, a 1 month notice shows their intentions and if they want you for the long term then they shouldn't be worried about how easily they can get rid of you.
By the way, in the UK they don't need to give a specific reason to fire you in the 1st 2 years, as long as they pay your notice and holidays.
All their other promises aren't worth the paper they're written on, and the fact the contract explicitly retracts any other promise enforces this.
It sounds like they want their cake and to eat it, which in itself is a big red flag I would stay well clear
Reply: Wonderful, then it shouldn't be too much trouble updating the contract accordingly. Surely Mr. Employer, you would want to make sure all the corresponding details are correct with the intended offer.
Now, I live in DC so this is a lot easier for me than for people who live in other cities. But K Street and Old Town are chock full of Societies for the Advancement of Whatever, who always need technical work done, and there's rarely a problem finding a "Whatever" that you believe in (or just think is cool).
A few thoughts on this:
1. The "cool" factor should not be underestimated. One of my favorite jobs was sysadmining at Mount Vernon; it's not that I particularly believe in George Washington, but that is a mission that is undeniably "cool".
2. You will not make remotely as much money as you will in the for-profit sector (see above), but you'll have a much better quality of life. I spent years as a sysadmin without a pager, because they really don't care if the server goes down overnight. You will also (in my experience) have a much freer hand with what you do than you do in a tech company. If their brief is lobbying for human rights, they neither know nor care what stack you use to implement their intranet.
3. Org work has a very specific annual rhythm that you need to understand to work with. Every year there's a conference, a publication of some sort, and a membership drive; each of those is an "all-hands-on-deck" situation that lasts about a fiscal quarter (and you probably will be stuffing envelopes and manning a booth and checking people in). That leaves you one quarter per year for infrastructure work. Use it wisely.
It turned out that the mission was more of a very well executed recruiting and sales strategy than what I felt every day at the organization. Looking back, the recruiting effort talked about their culture and values so much that I should have known they were very insecure about something. The lower compensation wasn't required by the company's financials from what I could tell, nor was it made up for by especially meaningful work. Unsurprisingly, the organizational flaws of not valuing employees and cutting corners also showed up in other ways, most painfully in the form of amazingly bad code and hostile managers. The job was unbearable for me, as well as for many others.
I think the takeaway is that honest, successful companies should be willing to fairly compensate their employees. If a company can do that but doesn't, you should reconsider working there.
1. I want to be working on helping scientists, and this influenced current job search. Beyond personal satisfaction, this also has practical benefits: all things being equal, if you're motivated by the company's mission you'll be more focused (more at https://codewithoutrules.com/2017/08/03/stay-focused/).
2. There are jobs I simply won't take, because I think they're immoral or unethical. Other jobs I'd probably only take if I was desperate for money, since they seem pointless. (more at https://codewithoutrules.com/2017/08/07/do-something-useful/).
That being said:
* If you're bored, you will enjoy your job less.
* If you're working crazy long hours, you're actively undermining your ability to do your job. Doesn't matter how important it is, working longer won't actually help. (more at https://codewithoutrules.com/2016/08/18/productive-programme...)
So basically, my take is: finding someplace that you think is worthwhile and is a good work environment. Any, of course, pays you what you need. Living below your means can give you more flexibility in what jobs you need to take.
Its mainly for practical reasons, they tend to pay less.
I once turned down a job that paid more than another one because they wanted me to wear a tie.
Can you share the circumstance that you're mulling over? Good paycheque, ambiguous plan?
Also, I've found that the more a company talks about how great their "culture" is, the shitty it is in actual practice.
Dodged a bullet there, considering that those options would probably be underwater.
The nonprofit sector has its share of frustrations. Nonprofits are subject to auditing requirements that restrict them from doing things that we take for granted in the for-profit sector, and fundraising campaigns were always really stressful. But, by and large, it was four years of productive, meaningful, good-quality work.
(Later on, other studies have cast doubt on the earlier findings, but from a mission perspective, I found that the employees really care about the drunk driving problem, and are proud to work on a product that can reduce the rate of drunk driving.)
I ask myself that question before taking a job, so that nobody else will be able to.
As for the inverse, I've avoided many large tech companies because I felt they broadly lacked a mission.
I don't regret following my proverbial heart from time to time, but I do actually regret not trying out one of the tech giants while I was still in the US - some domains and problem spaces are hard to work on elsewhere, Greater Mission (tm) or no.
So far I haven't taken a job because of a specific mission (I'm happy as long there actually is one beyond a sales pitch), but denied or ignored offers from companies where I would have moral problems with what their doing.
At the bottom it says "Powered by Trackiva" which looks to be a splash page service.
> Trackiva is the platform that powers the famous TechCrunch Battlefield application selection process.
So really it sounds like this splash page service, which looks to be relatively unknown in Google is insecure, making (at least) some of the OWASP Top 10 vulnerabilities.
Apparently the app is made by this company Fardini Media (https://www.fardinimedia.com/). Hopefully they'll find this thread from a Google Alert or something and fix it.
Part of me cynically thinks the latter, but another part of me thinks a lazy developer could have taken shortcuts with what they saw as a less important part of the site. Either way, it's bad news and I hope they address it soon.
A website I would've never expected it was https://www.pm.org/, a community website for Perl developers run by ... well Perl developers. https://what.thedailywtf.com/topic/1874/perl-mongers/5