What if I am a JavaScript wizard who is also a backend wizard, and I know a lot about CSS/HTML and browser quirks, but I couldn't design my way out of a wet and ripped paper bag? Can I be awesome too? Or am I designated to the waste bin?
Because that would suck. I don't like the waste bin. It smells funny.
If you were a full stack JavaScript wizard AND you had solid design skills, you would be a unicorn with hooves made of diamond and a jet engine strapped on its ass.
* Learn & use Bootstrap. A manager actually told me to use Bootstrap instead of a custom webapp design created by his in-house designer once. The defaults are fine for a surprisingly wide range of projects.
* Learn some design basics, like the rule of thirds, typography and picking palettes from colour wheels.
* Don't be afraid to copy other people's designs. Conversely, if you're copying whatever is in fashion right now (I'm looking at you, long, scrolling pages split into sections of type/images...), then you might be better off just using Bootstrap.
Seriously. Design is easy:
1) Typesetting. Just put the text where it should go.
2) Colored backgrounds! Everyone likes color.
3) Responsive. Make it look good on mobile as well as many resolutions (max-width the main content area, use a framework).
If that's honestly true, you're punching well above the majority of people who work in the industry, and you have a highly valuable skillset. Plus you come with free ice cream :)
* The money to pay a junior developer who won't be productive until they're trained (probably a few months).
* The money to pay a more experienced developer to train someone rather than working on your app.
* The wiggle room on your deadlines to be able to slow things down for training.
* The stomach to live with the fact that an experienced developer may become available two weeks after you've hired a junior dev.
Depending on your requirements it could be the right call.
A bootstrapped startup is almost never going to have the capital to make this feasible, but a big company might.
Java developers are easy enough to find, so it rarely makes sense to spend months training someone. Ruby developers are a bit harder, and the training is almost mandatory if you're looking for Haskell developers.
That said, I would like to see big companies take a leadership role in this stuff. My company is always complaining about how hard it is to find qualified people. We've got the time and resources to run a bootcamp-style training course. We could bring in 30 people and train them for a few weeks and offer junior positions to the people who performed best. The people who were passed over still have valuable skills they can use to be hired by other companies.
Just seen this. Funny you should ask that, but I am actually working with somebody new to web development on a project right now as a sort of work experience thing. If you have a bit of time every day it's actually not that hard to teach somebody new. I highly recommend it!
Don't bother. I'm a front-end developer that happens to have a degree in design and no one from creative listens. Or they gripe about interrupting the "creative process" when I point out problems in the design intended for browsers before anything gets built. Telling them their "creative process" is just their opinion falls on deaf ears.
This guys is being pretty hyperbolic when it comes to the requirements for design-related skills. Perhaps that is the bar they set at Cloudera, but here are a lot of people out there that do 'front-end development' who don't have corresponding design skills. There are also classes of people out there called 'designers' that are particularly suited to that line of work.
I believe I say in the article that if you have 5 of the 7 things that you're in solid shape. You certainly don't have to have any of these things, but having them helps...
Being a front-end web dev sucks. You need to know browser quirks, know about design, know UX, know JS in depth, jquery of course and even backbone and/or angular are now expected (with any other framework being a plus). And the back-end guys learn mostly one language and stack, e.g. .NET and maybe SQL (if there isn't already someone dedicated as a DB guy). Then they still wonder why you are bitching about vertical centring, "isn't that just stupid CSS, here I'll help you, type in vertical-align:middle." The worst part is when you are working with a graphical designer (who knows nothing about the web) and sends you impossible designs, and a client who bitches if any pixel on that magnificent masterpiece is missing in IE6/7/8, because that's the browser he is using on his old PC, when his iPad is charging.
The grass is always greener on the other side. Working with, say, .NET stack you still have, in practice, to deal with substantial SQL apparatus. These two worlds (C# or VB.NET and SQL) are sufficiently distinct to form what is known as impedance mismatch (structural incompatibility), so one also has to work with an ORM such as Entity Framework which introduces another level of complexity, and so on and so forth.
Back end on Django rocks. Until you are looking for a new job. (Though I disagree on the one language thing, at least a conventional language, plus SQL, and you need to at least know the basics of HTML / CSS / JS)
Did I misunderstand something, or does this article just list all the reasons it's a bad idea to be a JavaScript developer? (apart from the 99 reasons that is JavaScript itself)
basically: you use a language that is the envy of noone, to work with things like web browsers, the DOM and CSS. Anyone would want good money to do that...
I do pretty much what the article describes and you echo the sentiment I get from dev friends who hate working with CSS and the DOM! I enjoy it though. There's a lot of art to it. I have absorbed a decade's worth of trivia that lets me usually do the right thing first time or find the solution quickly. And I generally get to be the interface to other teams (like designers, content people) which I like too.
Yep, the way I see it is that both backend and frontend development have their bad parts: you either faff around with broken config files, or faff around with broken stylesheets. (Obviously both have their good sides too). It comes down to which you find easiest to tolerate. E.g., I don't enjoy fixing CSS quirks in IE6, but I find it a lot less painful than trying to figure out why my fastcgi daemon keeps crashing.
Thankfully many/most of us don't have to worry about IE6-7, and IE8 is falling off (mostly)... the app I currently work on is only IE9+ and modern browsers. I feel that IE9 is really the only legacy browser with significant market share.. once that's passed, it will be better for all involved.
I've been dealing with browser quirks since the mid 90's... there's never been a better time to be a web developer. That said the browser tech alone has exploded with CORS, Web Sockets and WebRTC ... that's not counting the ground gained with node.js, mongodb and others...
The landscape is rapidly changing, so who knows what the near, and the next couple of years will bring to the table. Golang, docker.io and coreos are other things to keep an eye on.
The common denominator of all that is wrong with development today is the internet. Work on a library, thick client, compiler, or anything like that and you are fine, but work too close to any of the tiers in some kind of internet/web based application and your day is filled with misery.
Hopefully this internet thing will just fade away soon and we can all go back to real development.
Web development is a complex ecosystem. As a front-end dev I don't get to control much: many types of devices and software might run my code or display my HTML. Catering to that is the nature of the environment, and that heterogeneity (of devices and software) is what makes the Internet great.
I disagree that catering to that fills one's day with misery. In fact I think it's fun and I wouldn't enjoy working on a library, thick client or compiler quite as much. That's ok, development is big enough for us both to find something we like doing, without needing to denigrate what we don't like.
Also, even for a front-end person, those don't have to be mutually exclusive options.
Case in point: this week I am working on both heterogeneous end user-facing UI stuff AND [relatively] controlled-environment node-based webdev tooling for our FE team. I enjoy both types of challenges and think its healthy not to get too pigeon-holed into one such context or the other.
Which is why I personally let the designer(s) faff around with broken CSS and automated install scripts faff around with config files. Leaving me to fully enjoy my life of solving behaviour problems.
This is the solution. Having just automated our multi-server, multi-purpose configuration using Ansible, I can't tell you how many orders of magnitude better my life just became.
I'm in the exact same boat as you MDCore - the job description describes me decently well, but I too have my pick of jobs. If you need to hire yesterday, this company should consider hiring a UI person and a JS person separately.
My thoughts exactly. I love to learn new things, but they have to be interesting. As a C#/Unity3d game developer, most books and articles I've read lately for work been about data structures, algorithms, high-level OOP and functional programming concepts. May be it's my personal taste, but quirks of IE developer's code and implementation details of CSS sound like a lot more boring things to learn.
I dont understand those job ads. What kind of person honestly describes themselves as such? Maybe I am just too jaded, but god damn, note to self: kill myself if I ever use one of those titles.
Reading this reminded me of a post by Yossi Kreinin, the author of the C++ FQA (http://www.yosefk.com/blog/low-level-is-easy.html ). It's a good read and it will show you the whole thing from a different perspective.
I would tell anyone getting into web development right now that if you want to be in high demand, become a JS wizard. And of course, the front-end is part of the package unless you box yourself into Node.
To get to the level the author is talking about is quite daunting. I feel that JS is sort of a second class citizen to most back-end developers. Web projects which are touched by an HTML / CSS developer, a designer and a back-end developer are common (not always a team, maybe they are all contracted to do their bits as needed and don't work closely together.) Often the heavy lifting with the JS goes to the back-end dev because the HTML / CSS dev isn't really a programmer beyond Googling for Jquery snippets. The problem is, the back-end developer usually isn't a JS wizard either. A lot of developers I come across make a mess of copy and paste in the JS. And I don't spend enough time in JS for it to feel natural to me. If I could add one superpower to make my life way easier, it would be the things the author is talking about.
I see a lot of threads with people asking what to learn. If you are going to be a web developer, then JS is always a damn good answer (or if you already know JS, go back and level up.) I really love to spend time on the server side. I want to put my time into Linux, spend a lot of time in Go and learning other languages. But that doesn't make a lot of sense for a freelance web developer.
ETA: Actually, high in demand is probably the wrong way to put it. You don't have to be in high demand. Small markets can be as lucrative or better than much larger markets. And then there the fact that there is a lot more to being a successful web developer than being a code-monkey. But the things the author described is certainly a super power in web development.
> I feel that JS is sort of a second class citizen to most back-end developers.
I'm not what one might consider a back-end developer (or a web developer at all, for that matter), but the overgrowth of web tools in the web 2.0 aftermath has made web tools somewhat hard to ignore as of late, so I had to sporadically develop what can be considered back-end code. Even front-end, which I have done grudgingly.
To me, JS -- and in fact the whole web environment -- is a second-class citizen. I come from a vastly different background (embedded and systems programming), and the fact that people manage to write anything useful with today's web technologies is astounding. I honestly admire the craftiness of web developers, although I have very few good words to say about pretty much anything else that comes out of their hands.
I cannot help seeing them as second-class citizens because:
1. They are simply tools made for different purpose. HTML is there to annotate the structure of some content, CSS is to annotate its appearance, JS is for some limited interaction. What people managed to build with these limited tools, compared to the crap we were writing the last time when I seriously touched web programming (let's just say that PHP wasn't yet popular when that happened), is astounding, but I cannot help wondering if the web wouldn't be a lot better if people had actually stopped to think about better tools for a moment. Every time I see yet another awesome demonstration of a JS game, my initial enthusiasm is chased away by the realization that thirty years later, people are still enthusiastic about stuff you could make on an Amiga, were it not for the gazillion cycles wasted between the hundreds of abstraction layers involved in painting a pixel and for the latency involved with pretty much every I/O operation.
2. It's shaggy. Dear God, it's shaggy, full of barely-documented hacks. If you want your webpage to have a drop-down menu, there's a thousand something.js packages that help you do that, but all of them have their own quirks, their own issues with styling, their own little manner of use and so on. It reminds me of writing X11 applications using nothing but Xlib, when everyone was using their own menu widget that worked in a slightly different manner from every other application. The Unix desktop was not too fun to use back then, and the fact that people not only consider that kind of behaviour to be OK now, but actually want it, is beyond comprehension to me. It doesn't help that a large portion of the community seems to struggle with even the most basic programming concepts, which makes reading source code or documentation a very unpleasant experience.
3. The tooling is terrible (but this one is becomming less and less of a grievance).
The author is describing at least 3 positions on his post, it is insane to be responsible for the amount of work that it requires the proccess of building a web application.
It would be better to hire 3 different amazing people on their field (front-end dev, back-end dev and designer) and most of the times you will get a better result. two heads thinks better than one.
I (the author) would agree that it's insane, but it's often the case that when products get created, there's only one UI developer at the start. More importantly, if you DO have all those skills, you'll keep getting those kinds of opportunities.
Of course sometimes you have to do the hard work, but now that you are hiring instead of trying to find a person that master 3 fields, look for someone that master two of them, maybe the two where you feel less comfortable, a designer can easily fit front-end or a back-end dev is able to work on front, that may help to find someone capable to start working and later they would learn the next set of skills you need to be considered a unicorn, hackers love to learn.
I'm one, but I've had 26 years of experience in programming and software development to learn the stacks. At the company I work for arguably 4 of the 8 developers are full stack developers, so we can't be that rare.
One thing that I'm not seeing here is the long view. Sure, learn JavaScript, but recognize that due to its sub-standard nature it will be a transitional technology until a better run-time for web apps than web browsers comes along. JavaScript's popularity now is akin to the massive success of Visual Basic were a large number of adequately skilled programmers could crank out the needed business applications. JavasScript allows for much the same, and there's nothing wrong with that, it's just not something that will last into the future. So instead of learning JavaScript, learn how to program, how to develop software, and how to keep your fire alive so you want to learn the new stuff that will eventually replace what you're using now.
I sure as heck don't want to go back to Visual Basic, and I look forward to the day we don't have the HTML/CSS/JavaScript morass to build our software on.
In all fairness though, it's very easy to bash JS, but the anonymous functions etc., that are really core to the language are pretty powerful. I used to hate it a lot more than I do now, but one day I realized that apart from its more patchy areas (no strftime, what?), it actually covers off a lot of coding styles and patterns you need in order to get stuff done.
Functions being first class citizens are all JavaScript really has going for it (that and a captive audience), and any new web oriented language could incorporate that as well as improvements over JavaScript's awful everything else.
Not that JavaScript isn't useful - it is, and it does allow you to get things done. But imagine the uncountable number of man years that have been wasted coping with JavaScript when it's clearly obvious that something better would have made our jobs a lot easier.
Yeah true, I think you've hit the nail on the head - much as I sometimes wish something like Python were the standard instead, the lambda functions are fiddly (even if the list comprehensions are great).
JavaScript has been around long enough to arguably be called a mature language. It doesn't really need to be "better" (any more than any other language). It's the environment that's crappy - the Browser. But those aren't going anywhere. You're going to be waiting a long time before something supplants it.
I think it's a great thing to aspire to (I certainly do), but yeah, don't think you could claim to be there until you'd put in some serious years, there's just too much to know, too many languages with too many weird edge quirks.
Here's a question: for a decent frontend developer who's still far away from the "master" level he describes here, is it worth chasing mastery or might it be better to branch out to other skills, like management?
I think I'm a solid frontend developer, but I'm a few years professional experience away from the level he describes here. I know my way around HTML, CSS and the various browser quirks - though I'm still learning the idiosyncrasies he describes here. I've written a ~10000-line app in Angular.js, but my Javascript code is still sloppy, and is nowhere close to my knowledge of Ruby. I'm gradually picking up the basics of design and UI as I go, but that's a whole other mountain which I could climb for years.
"That guy I offered that car to (not really) took a job at a startup and he’s the guy. He’s THE front end developer for their product which doesn’t exist yet. He gets to point to that thing, a year or two from now when it’s worth a bazillion dollars (I do wish him luck, after all) and say, “I did that.” There are people out there, right now, who get to point at Twitter, Facebook, Gmail and Google Maps, at the Iphone’s UI, at Github, at the YouTube player – stuff used by millions upon millions of people – and say, “I did that.”"
Thing is, few products are built by one superhero. I'm wondering if, rather than transform yourself into a magical-unicorn designer/hacker - it might be better to get solid at development, solid at design, but aim to only get good enough that you can manage people who are better at you in those areas?
> I'm wondering if, rather than transform yourself into a
> magical-unicorn designer/hacker - it might be better to
> get solid at development, solid at design, but aim to
> only get good enough that you can manage people who are
> better at you in those areas?
Depends on your definition of "better". The market clearly treats the three skills (dev, design, management) as separate things, so really you don't even need to be "solid" in more than one if you define "better" as "above average salary". If you define "better" as "can move the project forward without finding another person to help", then becoming a "superhero" is what you should do.
Note that "we're still figuring out what this product is" stage startups really hope to find these "superhero" types, as they can litterally breathe life into a product by themselves. Larger companies can't depend on hiring people with all skill sets, as they're too rare.
I'd say rather than chase after things for their perceived value, do what you love. A lot of that esoteric knowledge is just the byproduct of doing what you like to do for years on end. If you like what you're doing now, keep doing it, get better, learn more.
As for few products being built around one superhero, that's absolutely true. But it's often the case that when products get created, there's only one UI developer at the start. In the article, the guy I'm referring to was one of the first developers at simple.com - how cool is that?
Am I the only one who thinks a lot of this is a little too specific on so many things? This thing reads like a list of things discovered while building an app, now they're making it gospel to know all these nuances. Knowing the trialing-comma thing, for example, is an I.E. only thing. What if you just don't code with trailing-commas to begin with because it doesn't look right, so you've never come across that? Anyway....
A lot of these things someone will figure out when they get stuck with a 5 second google search.
A lot of these things won't matter as legacy browsers fall out of scope.
A lot of these things won't matter if someone's utilizing some form of frame-work to help them glue code together.
Maybe this level of detail would be important if you're building custom JavaScript frameworks, or whatnot, but for 99% of the UI code out there....
...meh, I don't feel not immediately knowing a lot of these things would prevent anyone from developing a solid UI application.
(I'm going to write later how to get the most out of a team of typical web devs who aren't gurus or rockstars or ninjas, but yet manage to make compelling applications that make customers happy.)
EDIT: I'm only commenting on the first couple of items in the story, because I'm not even going to address the separation of front/back, and manageable team sizes.
> A lot of these things won't matter as legacy browsers fall out of scope.
As an engineer whose recent focus has been front-end, I wish this was true.
The iOS7 rollout is what's been on my mind lately. That version of Mobile Safari had a number of new quirks/bugs which caused some significant usability issues on the site of a major automaker that I've been working on most of this year.
After poking at one of the biggest problems for two weeks, we eventually came to the conclusion that there was no fix available, and the choices were (a) live with the problem (b) entirely re-engineer some components just to accommodate iOS7, or (c) gracefully degrade for the newest version of what is likely the most significant mobile browser.
I've enjoyed watching and participating in a lot of the progress and excitement on the front-end over the last 10 years. But this development really depresses my enthusiasm. It was kindof understood years ago that, sure, for now we might have to make sure we knew the quirky minutia of each of the major 3-4 rendering engines, but the promise was the quirks would fade, browsers would converge on standards, we'd paper over whatever Microsoft couldn't/wouldn't manage to fix themselves, and eventually get on with the actual engineering.
Watching another major vendor introduce new quirky minutia in 2013 makes me wonder if front-end engineering will always mean that you'll have to fill up your head and your time with ephemeral, non-generalizable knowledge that will never really help you grow into a better problem solver.
While I think it's a great time to see JavaScript actually come to the forefront of software development. I've been a pretty big fan of the language for a long time. Well before Crockford's good parts book. And well before modern browsers. I remember the v4 browser days, and how painful DOM interaction was.
I've been pushing for node.js and MongoDB for over three years now, and finally seeing them gain a lot of traction. Right now I'm pulling for docker.io and CoreOS to gain the same kinds of traction (and learning go).
I don't think what the author is asking for is impossible.. but I would be more interested in either stronger core development skills or stronger design skills, you won't likely get both. I started off doing more design and that was over a decade and a half ago. Today, I reach for balsamiq if I want to mock something up, and tend to go very basic and neutral for UI to start with. You can add more later, especially if you have an artist at your disposal.. Beyond this, clean design is finally gaining ground anyhow, though I am getting tired of very bootstrap like sites.
I've seen the good and bad, to very bad.. you deal with the issues you have come across personally, and likely won't know how to fix a specific issue you haven't come across... today, I'd say a JavaScript developer should know at least one test framework, and one module framework. Should at least understand closures, and some of the ES5 extensions (especially to arrays), understand how currying techniques work... and experience with node.js and mongodb is really important.
Knowing another server-side framework is important, but dogma from a various server-side frameworks tend to cloud how development works in the JS mindset... There's a lot of changes happening in the past 2-3 years (a lot driven by node.js), and more to come... just being open minded and trying to understand some functional concepts is important a well.
Personally, I'm tired of some of the recruiter emails that I get.. generally a few a day, and mostly either distant locations I have little interest in and/or for salaries I wouldn't consider.
I applied for a backend and told them I did node.js and does javascript dev (which they were looking for).
They tested me on front end shit. And thinks that javascript is only front end.
While there are many down falls with node.js it still pay the bill, interest tech, and I wish people would realized that just cause you program js you doesn't imply that you want to do front end.
Unless you are handling massive amounts of concurrent connections, are there not better choices than Node for the server side? Its still a fairly new technology.
Node does offer a lot of advantages beyond just many concurrent connections... A single language paradigm for client and server is big... the exact same language/structure/models for client and server communications and validation is pretty big. Many client-side tools utilize node.js these days as well.
In general node.js combined with npm bring a lot less friction to development than other languages. Using node to create shim services for a front end communicating through to different backands is brain dead simple as well. In fact there's been a few times that creating a service in node.js to communicate with an ill-defined backend was so much easier in node compared to the static language the main application was working in it was a no brainer.
Utility scripts in JS can also be pretty useful.. any kind of stream manipulations work well in node.js too.
This doesn't even mention that JSON (current data transmission structure du jour) is native to the environment. And storage systems like MongoDB (couch, rethinkdb and others) is really transparent to node.
I couldn't even begin to all list the advantages, but here are a few.. the event loop system, libuv library bindings internal to node.js, language singularity, the npm system and over 40k modules...
Node's event loop is very easy to work with since all the standard tools are async from the start. It's not like eventmachine where standard Ruby calls are synchronous and they can throw a wrench in your logic.
There's no need for a mature standard library. Things move faster nowadays and you can't wait for things to get standardized. Node embraces the open-source spirit and trusts that the best libraries will rise to the top eventually.
And then you do all of it in JavaScript.
JavaScript is actually a top notch language. Cream of the crop. Lambdas, higher-order functions, apply/call, and OO. What more could you ask for from a dynamic language?
I'd say yes to some degree; you have Javascript, and you have a deeper level involving the environment. On the server, that's Node and its API and the available libraries and how to use them, webserver configuration, *nix server management, etc. On the client, it's the stuff mentioned by the author; front-end libraries, the various environments, CSS, HTML, etc etc etc.
Both require their own specializations. I wouldn't say they're mutually exclusive, just that while the constant is Javascript the language, the environments are widely different.
I don't think Javascript Developer and Front End Web Developer are mutually exclusive. They certainly aren't the same, but they aren't mutually exclusive either.
Though I do agree the subject of this article would be more suitable if it were Front End Web Developer as opposed to JS Developer.
That's not what a 'unicorn' means in this context. Yes, there are quite a few "average to good" programmers. But a unicorn is a programmer who knows so many esoteric languages/frameworks/platforms that they are nearly non-existent in the wild and almost impossible to hire.
He mentions using (1) vi or emacs instead of (2) Textmate or notepad. I wasn't aware that one could use (2) in place of (1). How is that done? Does one need to SFTP a text file from the server to a client GUI OS, modify it, and then SFTP it back?
I use Transmit to connect to my server. Then right-click "edit in" and your favourite editor. When you save, Transmit will automagically upload your file for you ;)
Though I still recommend using something like git, because at some point you will do something stupid and you probably won't find that backup :(
I think hn user nostrademons has had some of the most interesting comments on front-end development and has posted about some useful skills to have. But judging by his comments the most important skills appear to be curiosity, hard work, and motivation to make something. True, there is an incredible amount of trivia in developing for the browser, but since the reason for the trivia is that your program may be run on any of a billion or more devices, it seems worth the effort.
Those skills are important because the front end field is still in flux and while lists are a great starting point it seems unlikely that there is a good exhaustive list. (I'd love to see one if there was.)
I just realized the article was from 2010. Good thing much of it still applies.
I think what the recruiter meant when he said "those people don't exist" was really "those people aren't available to you." In a highly competitive job market, these "unicorns" can get any job they want, or even stay independent, and both make more money and have a higher quality of life than most startups could provide. Recruiters know this as they are the ones trying to locate these people, but hiring managers might not have this perspective.
One thing about being a JavaScript guy is that it's quite fragmented. For instance, this guy's hiring for a position that uses MooTools. In my experience, MooTools (while a great framework) isn't used very often. The framework you know and love, and the job you want don't always match up - especially if you're going to work on a product that's a few years old.
This is my problem with JS. I've worked primarily with C#, done some Java and am currently doing some work with Python...all of which seem to be fairly consistent on functions that deal with problems, granted you get some overlap and redundant tools but there is some what of a standard. With JS, where does one start? Maybe I've just been too spoiled with what I've worked with thus far (jr programmer here) but in the times I've worked with or attempted to work with JS it has always left me looking for some kind of foundation or standards. So if any one out there enjoys JS and has some pointers on building a foundation, please advise...because a lot of the tools I see seem useful but I can't find any consistency in the projects I look at. Or rather, the only constant is that everything is always different.
Article title: Why it's good to be a JavaScript developer
Article content: Why it's good to be a JavaScript developer who is also a back-end developer who is also a systems administrator who is also a designer who is also a ...
This guy wants to hire people with 15-20+ years of experience, and I'm willing to bet he's not willing to pay for it.
People say this all the time but it's not true. There are a bunch of things in JS that just don't work (are compile errors) in CS. Like conditional expressions.
Because that would suck. I don't like the waste bin. It smells funny.