Instrumental | Onsite (remote during SARS-CoV-2) | Palo Alto, CA, USA; Chicago, IL, USA; New York City, NY, USA; San Diego, CA, USA; Longhua, Shenzhen, Guangdong, China
Can you imagine writing software with no debugger or logging, and you only get to run it every few weeks? That's what building hardware is like for many product companies. At Instrumental, we're building a manufacturing optimization system that collects data no one else can, and uses machine learning and visualizations to automatically identify defects and help product companies understand their assembly processes.
With ~35 people we are a small but mighty team with a collaborative, friendly culture. We value an inclusive environment and actively work to promote diversity in our team.
We also value good tools. For example, I manage the web app team - our deploys involve running a single command and take just a few minutes, so we deploy frequently and with confidence. "Watch mode" compilation usually takes under a second. We have "branch environments" to test any pull request in a production-like environment with real data. And we have robust tests.
Instrumental | ONSITE | Palo Alto, CA, USA; Chicago, IL, USA; Charlotte, NC, USA; Longhua, Shenzhen, Guangdong, China
Can you imagine writing software with no debugger or logging, and you only get to run it every few weeks? That's what building hardware is like for many product companies. At Instrumental, we're building a manufacturing optimization system that collects data no one else can, and uses machine learning and visualizations to automatically identify defects and help product companies understand their assembly processes.
With ~30 people we are a small but mighty team with a collaborative, friendly culture. We value an inclusive environment and actively work to promote diversity in our team.
We also value good tools. For example, I manage the web app team - our deploys involve running a single command and take just a few minutes, so we deploy frequently and with confidence. "Watch mode" compilation usually takes under a second. We have "branch environments" to test any pull request in a production-like environment with real data. And we have robust tests.
This article links to [1] as an explanation for the delay, but that article says at the top that Github has since updated their configuration instructions to help people avoid the issue.
I got frustrated with this and created BigConsole[1] to solve it. It's a Chrome extension that adds a Firebug-style split console to DevTools.
Then I tweeted about it, and Addy Osmani responded[2] pointing out that Chrome does in fact support multiline consoles with its Snippets[3] feature. It's still kind of obnoxious, but it does the job.
There are an infinite number of ways to fail and only a few ways to succeed. If you learn from failure, you have learned one way that doesn't work out of an infinite number. If you learn from success, you have learned one way that does work out of a small finite number.
Obviously there are some ways to fail that are much more common than others, but those tend to be based on lack of action, e.g. failure to actually ask users if they want to use your product before building it. There is plenty of material on those common sorts of failures, it's just usually phrased constructively, i.e. "how to do SEO" rather than "we died because we posted duplicate content on every page of our site."
Performance and goals don't have to mean the same thing. An example of a goal is "acquire 30 new customers by the end of the month" and the relevant performance metric there would be "number of new customers acquired." Better performance in that case might mean 50 customers acquired while worse performance might mean 10 customers acquired.
I agree that "it's easy to get frustrated if you bite off more than you can chew - so content yourself with learning simpler things at first." I don't think that's contradictory to what I wrote; one component of good goals is that they're achievable. In retrospect I can see how you would read that lesson into Dan's post, but what he actually wrote is that what you should do if you want to "build skill in the long term" is "setting firm goals and keeping track of what you're doing is a problem for beginners." I think that is not appropriate advice for most people.
Sorry -- some people struggle with light-on-dark text. I tend to like it (obviously) but I'll probably switch at some point for this reason. I also want to experiment with just making the text larger.
Would be interested in hearing if other people have experienced this issue and had success solving it.
Thank you for pointing this out! I was specifically trying not to say there is One True Way of setting goals but rather that science suggests certain kinds of goals work better for most people most of the time. However, I should have been more explicit in saying that no method will work for everyone.
I agree with the idea that if you know nothing about a topic, it makes sense not to set goals in that space before you know whether those goals will be achievable or not. But Dan's advice is given with the caveat that "The advice from now on will assume that you know at a very high level what you like, what you're passionate about, or where you want to go" -- and in any case I disagree with the notion that just trying a task for awhile with no end goals is a good way to accomplish something. (It is, however, a reasonable way to discover possible goals, which may have been more of what Dan was getting at.)
Great question, and there's a lot to say about it. As with most things, there is no right answer, but here's a starting point:
If you are sitting here thinking "I need some goals. What are some good goals for me?" then you should start by thinking about the things you are good at and the things you enjoy and finding the intersection. Alternatively you can think about things you think you might enjoy that would require learning new skills, or things you might not enjoy as much that could be useful in your life.
Once you have a topic, or a pre-existing non-motivating "do your best" goal, there are a few situations:
1) If you're a complete beginner and need help figuring out what a good project could be, I discussed some some thoughts in a previous post [1]:
Good beginner projects tend to be more or less copies of things people have done before.
I also recommend reading a how-to book and asking more knowledgeable friends for advice.
2) If you know somewhat more about the topic and you're struggling to get a different, more motivating perspective on a goal, I recommend doing what physicists usually do: putting the hard problem in the context of an even larger problem. To do this, ask why you want to accomplish the goal you're contemplating. (If you don't know why, go to step 1, or maybe you shouldn't be doing it.) I gave an example in the post of moving from "I should work out because that's a good thing to do" to the meta-goal of "I want to look good for beach season." Or you could move from "I want to learn to program because that's a good thing to do" to "I want to build Ticketmaster for my school" (for example).
3) If you just know you're interested in a general topic and are looking for ideas, I have so much to say about this it needs a separate blog post. This is definitely the best place to be.
What other characteristics make a useful goal? Also a topic for another post, but you can probably guess by now that I think one good baseline is whether you know specifically why you're doing it (beyond "it sounds like a good idea") and whether it is measurable enough that you can proudly tell someone specifically what you've accomplished.
There are a lot of different situations. Some common ones:
1) When people come to me and say "I need someone to build X for me," I usually say "I can help you make sure X gets done right." If the person contacting me isn't especially technical, that means I remove the weight from their shoulders of verifying that they actually got what they paid for when they hire another freelancer/contractor to do the job.
2) Sometimes people already have devs either hired internally or managed externally, and they're having trouble and just need someone to come in and tell them how to get back on track. This might involve some code but it wouldn't actually be my job to write the code, just more of a training thing / someone to call.
3) Sometimes startups with non-technical founders in particular just need guidance on what they should actually be doing with technology. They don't know how it could improve their business, but they do know that they like what my software says it can do, and they're not sure what to do next. Usually these people are trying to compensate for a lack of a technical co-founder.
4) A lot of the time the initial email to me isn't looking for a consultant, and the business may not even have considered the idea; but sometimes especially larger institutions know that they want a consultant with intimate knowledge of the software they're working with. You can't get that by hiring a consulting firm.
Transitioning was easy -- I just started telling people I would do consulting instead of development work when they contacted me. I had intentionally not take development work that involved maintenance agreements for some time (I rarely built complete sites; I just built components or additions to my own open-source software). It also helped that I had spent a lot of time meeting with entrepreneurs and hearing about the businesses of people who had previously hired me. But there is a lot to know about consulting just like there is a lot to know about development and it takes some research and experimenting to deliver good experiences.
I can confirm this. I wrote quite a bit of open-source software that has attracted thousands of users over the years and now my clients find me instead of the other way around.
You need to do more than just write the software though -- you need to be active in discussions where people are looking for software like yours, because that's often how people end up arriving at your software. Ideally the software you're building also supports some other software with a decent user base rather than trying to do something completely independent; that way you have a pre-established target user base who may already be looking for your solution.
Additionally, I started out doing contracted development work, and now I mostly do consulting. It's less stress and easier to predict how long it will take. And I get to spend my development time on my own projects.
A final note: if you contribute to other open-source projects, sometimes you can get in touch with the primary maintainer and have that person forward you work they don't have time to do.
I actually implemented a system very much like this on an internal company network recently. For that purpose, it worked great. I don't think it would work in an open, public context, not least because an attacker can force your site to spam its users. However, when you are going to stay logged in forever on basically the same devices, having an email-based login system without a password is no more pain for the user than a verification email (since that's all you're doing anyway). Essentially you're relying on the website to generate a local, device-specific, secure password instead of requiring the user to create and remember a (likely insecure) password themselves.
What you should do is what you want to do, and if you enjoy both topics, there is no reason to pigeonhole yourself into one of them. It is possible to be successful by focusing on breadth as well as depth, although the challenges are different. You are the only one who can decide what is right for yourself and for the kinds of jobs you want to pursue.
As far as whether it's possible to be excellent at both design and development, the answer is clearly Yes -- if you have 10,000 hours to put into each of them. It's pretty hard to find a role where you can focus on two distinct areas for 10 years, but it's possible (though often when this happens, one is professional and the other is a hobby).
However, you should recognize that both design and development are very fast-moving areas right now, and so being an "expert" in one of them usually means you are good at problem-solving and you can search online competently. So there may be a lot more overlap than some people think, which would make it easier to be an expert in both.
If you are interested in management theory, the traditional view is that there is a tradeoff between specialization and productivity (think Scientific Management, Division of Labour, etc.). A more modern perspective is that jobs that require creativity benefit from job variety and task identity (basically the ability to work on more aspects of the problem rather than just being one small cog in a large machine).
From experience, people like Dan often don't make "well engineered software that is maintainable for awhile." I know Dan personally and he's a great guy, but what makes Dan valuable is his intelligence, intuition, and ability to Get Things Done. Sure, he can code, but lots of people can do that just fine.
I say No a lot. It's not fun to say No, but I just try to be honest. When you get to have these conversations a lot you gain useful insights... there are a lot of ways to help people other than building their product for them.
Can you imagine writing software with no debugger or logging, and you only get to run it every few weeks? That's what building hardware is like for many product companies. At Instrumental, we're building a manufacturing optimization system that collects data no one else can, and uses machine learning and visualizations to automatically identify defects and help product companies understand their assembly processes.
With ~35 people we are a small but mighty team with a collaborative, friendly culture. We value an inclusive environment and actively work to promote diversity in our team.
We also value good tools. For example, I manage the web app team - our deploys involve running a single command and take just a few minutes, so we deploy frequently and with confidence. "Watch mode" compilation usually takes under a second. We have "branch environments" to test any pull request in a production-like environment with real data. And we have robust tests.
Open roles:
- Senior Backend Engineer, Platform: https://jobs.lever.co/instrumental/4c155db0-8506-4096-ae7d-c...
- Senior Backend Engineer, Web App: https://jobs.lever.co/instrumental/317d0eb2-e2db-498a-b79c-6...
- Senior Full Stack Engineer, Factory Software: https://jobs.lever.co/instrumental/9d9cee6e-a0b2-4484-8171-7...
- and others at https://instrumental.com/careers