The Technology Architect will have responsibilities covering many aspects of software development, from maintaining the current code base for ExpressionEngine and CodeIgniter to developing new tools and applications under the direction of the CTO. The Technology Architect will also be required to help keep documentation for products up to date.

The Technology Architect is a full-time position (part-time is also available).

Full job descriptions and qualifications are available on the EllisLab Jobs page.

To apply email jobs@ellislab.com. Your email will include a formal resume, examples of previous work, and be a showcase of your use of email as a primary communication tool.

CodeIgniter is one of those things that just does a job perfectly. Take for example, the humble can opener. Whilst there may be a few other ways to open a can of tuna, the can opener just ‘works’ it serves a simple, yet extremely efficient purpose, and does its job with perfection.

Head on over to the CI Blog to read all of Elliot’s contribution. Are you a CI fan with something to say? Have your voice heard. 

I’ve been pursuing my Master’s of Education part-time since 2003.  I took a year and a bit off in the middle of there somewhere, but other then that, I’ve been pretty steadily marching towards it for 5 years.  In April I finally finished off the last of my course requirements, and last week I got the official paperwork; I’ve finally finished off the degree.  Huzzah! I’m now legally allowed to call myself a “Master”, um… not that I ever would.  Oh no wait, I would.

Stop by Derek’s blog and give him a hardy slap on the back. 

Due to the haste, the EllisLab.com site never quite got the attention that the other sites got.  I loved the cartoon representation of me, but the rest of the site was kind of ho-hum.

A few weeks ago we began talking about adding an employee intranet area to the site to serve as our staff home base.  That project fell into my lap since everyone else was too busy.  For about a month I dragged my heels, feeling very little motivation to tackle the project, until it finally occurred to me why:  I wasn’t happy with the site itself, so the idea of adding onto it wasn’t exciting me.

So rather then fight my feelings, I decided it would be fun to roll up my sleeves, blow the dust off of Photoshop, and design and build a completely new site.  With that, I’d like to unveil our new site. I hope you like it.

Justin is an experienced web developer, having created multiple web sites and services, maintaining commerce sites, providing support to both development teams and end users, all working with technologies that EllisLab employs in its current products.  As a Code Mechanic for EllisLab, you’ll come to know him quickly as his role will primarily be that of providing assistance to the Technical Support and Community Service staff in resolving difficult issues and finding and fixing bugs.  And of course, vacuuming the CTO’s couch to pick up what’s left of the box of Gobstoppers I dumped into the cushions.

Welcome aboard, Justin!

They say that in life, timing is everything.  In 2003, fresh out of college, Paul was hired by the Oregon Wine Board to build a website using our first generation publishing system, pMachine Pro.  That site had a number of needs that were not able to be met natively by pM Pro, so Paul, despite never having coded anything in PHP before, rolled up his sleeves and figured out how to develop those features.  He then generously donated his new code back to our community, which is how I first met him. 

I remember looking at his code and being blown away that he had only been coding a few weeks.  He was a natural.  He also happened to live in the same city as I did, and as luck would have it, my little company had grown to the point of needing some development help, so I offered him a job.  Paul became employee number three.  There was me, a guy named Chris doing tech support (who left the company years ago), and Paul.

At the time Paul came on-board, I was a few months away from unveiling ExpressionEngine, the secret new project I had been working on.  In order to stay focussed on EE, I turned pMachine’s development over to Paul; a risky move for sure, given how little experience he had.  To Paul’s credit, he took the challenge by the horns, dove head first into the code, and single-handedly developed the very next release of pM Pro.  A natural indeed.

As good as Paul’s technical skills were, his work ethic and commitment were even more impressive.  Paul immediately became my trusted right-hand man, and for the past four years has been an integral component to our success.  During those early years in particular, Paul was more like a brother than an employee.  I can’t express how grateful I am that Paul emerged in our forums one day, and helped shape who we are today.  I couldn’t have done it without his help.

A couple years ago, we had a similar good fortune in finding Derek Jones.  He had been participating in our forums, having built a couple projects using our software.  We needed to grow our team just as Derek’s career was transitioning, so we offered him a job.  Similar to Paul, Derek was very new to programming when he started, but he had that special mojo that enabled him to learn rapidly and get productive very quickly.  In less then two years Derek has gone from having little programming experience to becoming CTO of our company.  Impressive.

Paul, and later Derek, taught me my philosophy on hiring:  Hire people who are brilliant, who get things done, and who show great aptitude—and this is important—even if they don’t have a particular skill-set.  Skills can be learned.  The other stuff can’t.

So today marks a day of transition.  Paul Burdick is leaving to spread his wings, tackle some new challenges, and meet some personal goals.  And Derek Jones is emerging as the cornerstone of our technical team.  Paul leaves a big void to fill, but fortunately we’ve had some months to make the transition internally, and he will still be with us in a reduced role, so our development goals shouldn’t be affected. 

Thank you for all you’ve done for us, Paul.  You’ll be missed!

Comments can be found in this forum post.

Brian Eno said that repetition is a form of change.  He too was challenging convention.

Paul Graham says that ideas are all around us, but we ignore them because they look wrong.  He’s right.  Often, things don’t look right to us until someone else does them first.  How many times have we said “I wish I had thought of that!”, in response to a clever new concept?

I’ve had a new product idea for about a year.  It started as a vague concept that stemmed from my discontent with the state of blogging.  Most blogs have a very familiar format, a standardized navigation, categorization, and structure.  There is a fundamental similarity of approach, regardless of topic.  I’m a little restless and bored with the state of blogging, frankly.  I feel like we’re ready for a new iteration of the format. 

These feelings produced a small fragment of an idea, which I’ve been wrestling with for the past year.  It’s taken many months of thought, tinkering, and staring out the window to hone the idea into something that resembles an actual workable concept.  I’m still not in development of the idea, but I finally have enough of a handle on it to consider moving forward.

The point is that ideas take work.  They don’t just appear out of thin air fully formed and ready to craft.  They come in fragments.  In bits and pieces.  Ideas are like an onion.  You have to peal the unnecessary petals away in order to get at the core.  The simplest ideas often take the most work, mostly rejecting all the extra junk that isn’t needed.  Linda Tischler said it best:  “In an Escher-like twist, the technology that’s simplest to use is also, often, the most difficult to create”.

So don’t get frustrated if you seemingly don’t have any good ideas.  Each of us has ideas, great ones.  But they require that we think unconventionally, and most of all, that we be willing to work at them.  Thomas Edison said that genius is 1% inspiration and 99% perspiration.

1. Ignore everybody.
2. The idea doesn’t have to be big. It just has to be yours.
3. Put the hours in.
4. If your biz plan depends on you suddenly being “discovered” by some big shot, your plan will probably fail.
5. You are responsible for your own experience.
6. Everyone is born creative; everyone is given a box of crayons in kindergarten.
7. Keep your day job.
8. Companies that squelch creativity can no longer compete with companies that champion creativity.
9. Everybody has their own private Mount Everest they were put on this earth to climb.
10. The more talented somebody is, the less they need the props.
11. Don’t try to stand out from the crowd; avoid crowds altogether.
12. If you accept the pain, it cannot hurt you.
13. Never compare your inside with somebody else’s outside.
14. Dying young is overrated.
15. The most important thing a creative person can learn professionally is where to draw the red line that separates what you are willing to do, and what you are not.
16. The world is changing.
17. Merit can be bought. Passion can’t.
18. Avoid the Watercooler Gang.
19. Sing in your own voice.
20. The choice of media is irrelevant.
21. Selling out is harder than it looks.
22. Nobody cares. Do it for yourself.
23. Worrying about “Commercial vs. Artistic” is a complete waste of time.
24. Don’t worry about finding inspiration. It comes eventually.
25. You have to find your own schtick.
26. Write from the heart.
27. The best way to get approval is not to need it.
28. Power is never given. Power is taken.
29. Whatever choice you make, The Devil gets his due eventually.
30. The hardest part of being creative is getting used to it.
31. Remain frugal.
32. Allow your work to age with you.
33. Being Poor Sucks.
34. Beware of turning hobbies into jobs.
35. Savor obscurity while it lasts.
36. Start blogging.

We’ve been trying to fill a couple new job openings at EllisLab.  As I sift through several dozen applications, what I find most glaring is that very few of the candidates are currently part of our community or culture.  Some do have experience with our products, and they possess the necessary qualifications, but without that integration they feel like outsiders to me.

Historically, people from our community have emerged to fill new roles with us.  It’s been a very organic process, where we get to know someone on a personal and professional level well before we ever consider them for a job.  Unfortunately, that process won’t scale, so we must recruit candidates in a more traditional way as we grow. 

In order to maintain our authenticity and core values, must all new candidates come to us already integrated into our culture?  Ideally, yes, recruits should already be part of our family, as it makes the process much more seamless and natural, just as a Harley rider is a better candidate to work at Harley Davidson then someone who doesn’t ride. 

Unfortunately that’s not always realistic, so the challenge becomes how to best integrate new employees.  Harvard Business Review asks a similar question in a fictional case study called Authenticity: Is It Real or Is It Marketing?.