I'm not sure what the right ratio is, but the level of disenfranchisement is palpable.
144 karma · joined July 20, 2010
I'm not sure what the right ratio is, but the level of disenfranchisement is palpable.
But to your main point: the will is not in publishing this, but in spending every day winning hearts and minds in small town bars and community centers. I could certainly use some help.
Curious to hear if anyone else has found success with Rebuilding Rails, and what they found most helpful.
I found Outreach last year on a "Who is hiring?" thread myself and joined the team shortly thereafter. I'm now the lead for one of our two platform teams and I'm looking to hire experienced software engineers to help us scale our backend systems.
Outreach is a sales engagement platform. We've got great customers (https://www.outreach.io/customers/) and have raised around $60M to date (through a series C round). We just moved into a new office in the Fremont/Wallingford neighborhood of Seattle. We pay competitive market salaries and offer excellent benefits. For example, I just returned to work from four weeks of paternity leave and was welcomed with eight weeks of paid postpartum doula support; I can't express how thankful my family was to have four well-rested nights of sleep each week.
Our team is working to scale our monolithic Ruby on Rails application as our customer list continues to grow. We own our core CRM, API platforms, background frameworks and our bidirectional syncing systems with Salesforce. In addition to Ruby/Rails, we use MySQL, RabbitMQ, Elasticsearch and Redis.
For the backend role, I am particularly interested in individuals with strong software design/architecture skill sets and those who excel at managing complexity.
Please reach out to ted.kimble@outreach.io if you are interested. We also have a number of other engineer opportunities available, including roles in front-end development (React), data science and machine learning. See our careers page for all job details: https://outreach.io/company/careers/.
Whenever I need to make a little change I can edit locally in my editor of choice, commit and push to SWM where I can preview the changes before merging to my production bucket (all without installing Jekyll locally).
If I don't have my machine, I can also just login, edit the text and then follow the same preview/merge to deploy workflow.
[1]: https://www.staticwebsitemanager.com
Are there any features the community would love to see offered in a Jekyll-based CMS?
I recently launched Static Website Manager (https://www.staticwebsitemanager.com) to help bridge this gap between static and dynamic websites. Relevant to this discussion is our Form Responder tool, which provides an endpoint for your HTTP forms.
The cool thing is you can connect them to your Jekyll data files and then new form submission data will be committed (appended or set to a key) to that data file. New commits also trigger builds/deploys, resulting in a dynamically-updated static website. (They work across your branches, too, if you need to moderate submissions before merging with production.)
Stack: Ruby on Rails, PostgreSQL/Titan, Heroku/AWS, UI/UX tools
Resume: http://www.theodorekimble.com/resume.pdf
Contact: mail@theodorekimble.com
I'm a full-stack web developer with significant Ruby on Rails experience and a formal graduate design education. I enjoy understanding the technical and qualitative elements that problems pose in order to design and build elegant solutions.
I'm looking for remote contract opportunities or interesting full-time positions in Seattle.
Deleuze and de Landa were my primary inspirations during graduate architecture school. I wrote about how such thinking might be incorporated into a web design.[1]
[1]: http://kimble.co/2012/bottom-up-web-design-and-the-materiali...
Our startup is looking for a front-end engineer or designer to join our team on a contract basis (for now). The right candidate will need to possess demonstrable experience writing:
* HTML * CSS (Sass) * JavaScript (jQuery, CoffeeScript)
Bonus points for experience working in a Rails environment. Design skills aren't required, but illustration skills (icons, logos) will be a plus.
tkimble@nouvant.com
Both engineering and design are instances of the same type of problem solving process. But because design is focused more on qualitative and subjective elements, its state space is much larger and, I believe, its design solutions (or attractors) more fuzzy. Because of this, design and engineering actualize themselves quite differently in real life, often requiring different skill-sets.
And I think that because the web and application design disciplines require more engineering-thinking -- architecture, for example, must also consider spatio-temporal qualities -- most design-thinking is delegated only to the most superficial facets of the process. What would really help understanding is for more designers to push into the engineering side of things, and more engineers into the design side of things.
I am a full-stack Rails developer and generalist designer with a reasonable rate. I possess a formal design education (master of architecture) and a technical background (bachelor of arts, physics).
One is on my master's thesis and how a design can actually be the result of a complex dynamical system. The other is on the process of navigated a design state space during the web design process.
I'll be sure to post both here when they're completed.
I recently completed a four-year graduate design degree (architecture) after a lifetime of math, physics and not a whip of art or design experience. Here's my take on this issue.
Engineering and design are both fundamentally processes of creation. While both creations must meet one or more objectives, the types of those objectives often differ. Engineers tend to optimize for quantitative objectives and criteria; designers tend to optimize for qualitative objectives and criteria.
I think this difference has two significant consequences:
1. The solution space for designers (or anything with qualitative criteria) is much larger than for engineers. 2. There are many more opportunities for mediocre design than there are for mediocre engineering.
By point 2., I mean that not only is the solution space of design much larger, but there are also many more "attractors" of solutions. In engineering, the attractors have a strong pull and are more recognizable as such. And, because the solution space is more quantifiable, the relations between those solutions are more well understood and comparable.
In design, the attractors are more fuzzy and their locations in the solution space are often unknown. This allows anyone who can find a mediocre design solution (especially those who find "pretty" visual ones) to become a "designer". But good designers must do much more. They must understand the design space enough so that, from any starting point, they can justifiably navigate towards that same design solution.
This involves crossing certain thresholds -- bifurcations -- in which the nature of the design solution changes. Recognizing when to cross these thresholds is, in my opinion, a task perfectly suited for analytical thinkers. You don't need to be able to create visually pleasing designs to find the best design solutions. Visual aesthetics are simply one component of optimizing the already discovered design solution.
So my advice to engineers is this: forget about visuals. Design analytically, question the existence of design components and their relationships. If you cannot justify their existences and relationships, you need to somehow change their nature (bifurcate the design) until you can justify it. Often starting from the bottom-up is the best way to accomplish this.
Once a design solution is in sight, optimizing its visual aesthetics is much easier -- you've already framed its problem so well!
Finally, I must note the three tasks which are essential to the design process: research, experimentation and documentation. Surely these tasks are also vital to engineers, or anyone else involved in processes of creation.
---
(PS If anyone would like to talk about how many of the concepts of dynamical systems theory can be used in the design process (and the design itself!), I'd love to hear form you!)
Most recent work: http://kimble.co/web
I am a design generalist with a undergraduate degree in mathematics and physics and graduate design degree in architecture.
My ability to design and program -- and perhaps more importantly, to communicate in both languages -- provides significant value.
I work mostly in Ruby and implement design in code -- Haml, Erb, Mustache, Sass, Less, CoffeeScript are used frequently.
I recently released my first open source programming project: http://github.com/tedkimble/bruter.
Email is in profile.
I used to think of myself as an engineering-type person. I engineered solutions. Indeed, my undergraduate education was in math and physics. But then I began a lengthy graduate design education in architecture and, in the process, began to design solutions. I had become a design-type person.
Yet when I reflected on these two types of tasks -- engineering and design -- I realized they were not different types of tasks at all. Rather, engineering and design are two different approaches to the singular task of creation: design is creation in which decisions are based primarily upon qualitative metrics; engineering is creation in which decisions are based primarily upon quantitative metrics. I was instead simply a creative-type person, just one with an ability to approach problems with both engineering and design eyes.
Perhaps my most important observation is that engineering and design are fundamentally more similar than different. And by improving your abilities in either, you are improving your abilities at that which is similar: the creative process itself.
If you put your email in your profile I'd be happy to contact you and discuss more (or feel free to email me).
I'm a bit of unicorn: a designer and a developer[0].
I practice responsive front-end design and implementation and enjoy using Sass, Coffeescript, and Mustache. I have a graduate design degree in architecture.
I have over four years Ruby on Rails experience; I enjoy Sinatra and have developed my own miniature Ruby web application library[1]. I have an undergraduate degree in physics.
[0]: http://kimble.co/web [1]: https://github.com/tedkimble/bruter
Email in profile
Does it pass the test if it aligns to a grid, contains a pleasant color palette, has enough whitespace, hierarchy, and contrast? Or is there something more fundamental you strive for?
I think a formal design education would be much less concerned with the former, and more concerned with the latter -- what are your most fundamental first principles as a person, and how can you instill those into your design and/or design process.
I want to see more articles about that.
My opinion stems from two things. First, HMTL and CSS are trivially easy for me and consume only a small fraction of time I spend on the design process. I imagine this applies to almost all of those who share the opinion that you must know HMTL and CSS to be a web designer. You make a strong argument that this is not a necessity to being a top-notch designer.
But where my passion in this debate really stems from is my recent experience completing a graduate program in architecture. We were mentored to experiment with our medium; to uncover the materials' latent properties and capabilities, incorporating a bottom-up design process. This was (and is) highly unusual and controversial. Opposed to this is a purely top-down process, subject to the whims and inspirations of a single designer. The idea and form come first, and they are then imposed on an inert medium.
I see parallels to web design. Photoshop enables top-down thinking. The web (through HTML and CSS) are inert -- they are at the will of whatever form Photoshop demands. But I see something different in the code. I see a rich source of inspiration. I see capabilities, limitations, and tendencies. I see a "charged" source of untapped potential.
It's true, there are many valid sources of inspiration outside of code. Most of them, actually. But if no designers looked to HMTL and CSS for inspiration, I think a lot of potential would be lost.