I had a fantastic opportunity to spend the day at Constant Contact in Waltham, where they hosted the Engineers4Engineers Conference. I’ve been to a number of conferences over the years, and generally, the presentations are somewhat hit-or-miss. This one was all “hits.” I’m really glad I got the chance to go, even though it meant sitting through the mass of traffic on rte 128, leading to the intersection with rte 93 (on the plus side, the slow traffic resulted an in average 63 mpg for the trip, so I can’t complain).
All notes were taken on my cell, apologies for terseness and odd spellings! Also, this means quotes are *paraphrased*. Please don’t blame the presenters!
Laziness in Responsive Design
Ethan Marcotte
(*didn’t have the phone on for the first part of this – basic upshot: you can (and should) create a responsive site, if you’re willing to be the right kind of lazy about it. Let your content dictate the layout, not the other way around.)
Trick one – create a ratio-aware box: padding top 56.25% in CSS. Position relative.
Put your image box inside this w/an absolute position. The magic of css will take care of resizing the image.
Target divided by context = result.
In practice, this means: Element pixel width divided by container width
Use the :nth child layout.
Doc cell :nth-child(2n){your style} allows addressing every 2nd element.
Media queries: min-width nth child … By resolution in CSS
Current frameworks are HEAVY.
They require a lot of extra work, in your html, just to make the page draw nicely.
Right now, the web is in a similar place to the animation industry in the 1930s. When Disney studios started, they created an animation design framework that was lightweight, and worked well to describe and ensure every character’s animation quality, regardless of the story. We need similar for the web design.
See “The illusion of life.” Bio of Disney.
What’s needed in a new framework:
Content-out-layout
Light-weight. Brings the layout out of the HTML and into the CSS where it belongs.
How can we make the content feel at home regardless of screen size?
Use @media to *defend* your content, not to define it.
It should be device agnostic
Layout is only first step.
Initiation to Code: A Roadmap for New Developers and Their Mentors
Alice Mottola
Why hire juniors?
Junior devs are good for your team – making your devs learn to communicate and clarify.
22% job growth for sw engineers, but the stats for posted jobs are skewed highly toward senior not junior devs. But junior devs can’t become the senior devs to fill that growth unless someone hires them.
New Relic cut on boarding to 3 mo from 6 mo by adopting mentoring.
Just Like Aligators
Gators analogy: On Louisiana swamp tour, discovered that baby gators are taken and raised until they’re old enough to fend for themselves, otherwise the bigger gators would just eat most of them. The same should be true for junior devs – a strong mentoring culture can make all the difference.
The mentoring process can be defined in terms of noob comfort level phases.
(Note: the talk had content for both noobs and mentors, but my notes largely focus on the noob side, since, well, that’s me, and … cell phone typing)
Phase 1
Can’t do much without guidance, not comfortable being sent off to sink or swim – yet.
Metacognition: look it up, use it.
Plan an approach
Monitor progress
Reflect on the outcome.
Set *explicit* goals and expectations
Write it down.
Prone to:
Pitfall 1: I suck! (paraphrased)
Pitfall 2: power mad (You just learned to do something, think you’re good at it, but you’re just scratching the surface.)
Remember the hacking stages
(in formal hacking, not “let’s make an app, today!!” pseudo-hacking)
1 curiosity
2 control
3 conscious intent
Useful Trick 1: memory palaces. Make the images outrageous.
Useful Trick 2: use the product your employer produces.
Phase 2
Can see the path, can work independently(ish). Know what next problem is, but not how to tackle it.
Be a code entomologist. Generalize your bugs by categories.
– Stupid Little Things. Example: spelling errors.
– Framework may not work.
Have opinions even if, you’re wrong.
Get a deeper understanding of the tools you use.
Open opportunities for conversations.
Review others code even if you don’t feel qualified.
Find an independent project. Best of it’s for company, such as an internal tool or small product feature.
Phase 3
Still a lot to learn.
Pairing is becoming more collaborative than instructive.
Keep working on independent project.
Read stuff that’s over your head. Seriously.
Keep Learning!
Books:
Create rails apps.
Ruby under a microscope.
Renegotiating.com
Go to conferences.
Learn a new language.
Teach yourself design patterns.
Head First … book by O’Reilly.
Be a mentor
For mentors:
Near the end of this phase is time for an “Initiation”
– It should be “not trivial for someone at a higher level.”
– Demands communication w/senior engineers.
– Provides *demonstrable* value to the company.
Hint: Don’t tell the noob it’s an initiation.
Parting Note
Meditate on:
“A true initiation never ends.”
How to Build Innovative Technologies
Abby fichtner @hackerchick.net
Hack Boston founder
Harvard Innovation Labs
#1 There are no rules of innovation.
9 of 10 ideas fail.
Single biggest predictor of failure: sticking to the initial business plan.
These traits are common among startups that succeed:
– Eliminate waste
Learn the difference between value and waste. Remember: Ya Ain’t Gonna Need It (YAGNI). Don’t start off by building a bunch of stuff your users may never use.
– Start small
You can’t start something with a billion new users out of the gate. It’s not going to happen, so don’t try to start there.
Dominate a small market, instead.
– Deeply understand your customers
Example: Dropbox – there were a million cloud storage options out there, but no one used them. Dropbox started with finding their customers, then mocked up something they’d actually USE, then posted a basic signup landing page with a video of the walkthrough of the mockup.
– Always be learning
How can you be scientific about your learning?
Make a hypothesis, then test it.
Use Mockups, Talk to people.
BUT – don’t “lead” people to the answer you want. Put something in front of them, let them show you how (or *if*) they’d use it.
MVP it.
– Focus to Get Stuff Done
Ideas are a dime a dozen. How do you get stuff done.
1) Use a Minimum Viable Process.
Use Kanban – make the “work in progress” limit 1 item per developer, and make them short – max length 1 day.
Limit the “to do” column to a week or two’s work, no more.
2) Minimum Viable Design
Go for emergent design. Remember: YAGNI
Shorten the timeframe between times when we’re learning from our customers.
Rapid deployment makes it easy to experiment, get feedback, and learn from the customers.
Wiredreach is an example of a company that used rapid releases – it resulted in small, stable, easy to roll-back releases without huge emergencies (no fire drills!).
– Only go as fast as you can learn from users.
Don’t move items to the done column until the learning phase is complete. Have a learning column in your Kanban.
Q&A
How do you deal with someone who has “It’s gotta be perfect” syndrome?
– Not a fan of “release crap, and call it an MVP.” Don’t put out a crappy project, but DO put out a *minimal* feature set.
That said, if you have no customers yet, who are you going to offend? Don’t worry too much about offending users who don’t exist with a product that isn’t the end-all be-all.
Ways to acquire users?
Know your people and where they hang out. Pinterest had to hold physical Meetups with scrapbookers, in order to get people within their target demographic to sign up. Dropbox only needed to know which tech web site to post to. Knowing the customer is key.
Overkill
Katrina Owen
This talk was supposed to be on a very different topic but ended up being a fantastic demonstration of the importance of good naming in your code. If you name things well, the code is much more readable, and much more maintainable. Even by a stranger who comes to look at it 6 months later, after too many beers.
I didn’t manage to catch any notes on this one.