Startup from NUS looking for Developer

50 views
Skip to first unread message

Justin Lee

unread,
May 9, 2012, 7:45:31 PM5/9/12
to HackerspaceSG
Hey guys, 

Just helping a friend post this out.

=====

Dear Hackers community,

A NUS Professor from the School of Computing is looking for a self-motivated and independent developer who is proficient in Andriod application development and Web Services development to join a startup company which is currently in the making.

Due to limited budget, the startup is open to using other means such as stock options to compensate should they not be able to match the requested salary.

Interested parties can contact Professor Pung at dcs...@nus.edu.sg directly.

Jiang Fung Wong

unread,
May 9, 2012, 8:41:56 PM5/9/12
to hacker...@googlegroups.com
Is a professor allowed to join a venture? won't that affect their teaching schedule and quality?
Interested parties can contact Professor Pung at directly.

Junhao

unread,
May 9, 2012, 10:06:30 PM5/9/12
to hacker...@googlegroups.com, Jiang Fung Wong
It could be an NUS funded venture...

Paul Gallagher

unread,
May 10, 2012, 1:18:43 AM5/10/12
to hacker...@googlegroups.com
I've no comment about this specific venture, but it does prompt a tangential thought - one of the lessons that should be in a book called "101 things I wish I knew before I went to work for a startup":

#42: think like an investor when assessing a startup as a potential employer. Investors typically want to be assured that the company's IP is unencumbered before buying in. As a potential employee (especially if options or shares are part of the package) you should be just as concerned. If a founder is associated with an educational institution, that's a red flag that requires assurance (some institutions are very enlightened and expect their staff to gallivant around in private ventures, others have extreme positions that basically mean they own all the IP unless you have a concrete agreement to the contrary) 

(is there such a book? I just made that up.)


Meng Weng Wong

unread,
May 10, 2012, 1:20:41 PM5/10/12
to hacker...@googlegroups.com, hacker...@googlegroups.com
On 10 May, 2012, at 1:18 PM, Paul Gallagher <gallagh...@gmail.com> wrote:

> (is there such a book? I just made that up.)


I am planning to write Startup Design Patterns, following in the footsteps of Christopher Alexander and the Gang of Four...

Any suggestions or requests?

Stephan February

unread,
May 10, 2012, 3:13:39 PM5/10/12
to hacker...@googlegroups.com, hacker...@googlegroups.com
Anti-patterns are equally useful. Consider including those too.

Cheers
Stephan
> --
> Chat: http://hackerspace.sg/chat

Mingming Wang

unread,
May 10, 2012, 9:07:25 PM5/10/12
to hacker...@googlegroups.com
The common patterns of the founder's role, the founding team, share structure pre/after incubator/seed round, cost structure...

some of the trivial things in the beginning stage are not covered in details by books, only can be found in blogs...It'll be good to be categorized in patterns.


Mingming

Paul Gallagher

unread,
May 10, 2012, 10:14:38 PM5/10/12
to hacker...@googlegroups.com
On Fri, May 11, 2012 at 1:20 AM, Meng Weng Wong <meng...@gmail.com> wrote:
I am planning to write Startup Design Patterns, following in the footsteps of Christopher Alexander and the Gang of Four...

Any suggestions or requests?

Er, write it faster? ;-)

It's a great idea, especially if it focuses on micro-patterns covering the whole raft of the uniquely startup challenges. So I'm thinking more like a cookbook of patterns rather than just focus on a few mega patterns around business model for example. (Books like Business Model Generation _almost_ get the mix right [nice layout], but still a little too weighted towards the theoretical, and a little too thin on actionable patterns).

As an aside, I forget how many times I've read the "classic opener" to a patterns collection i.e. Alexander and the Architecture Analogy. 

But just yesterday I was surprised and delighted to read a new take, in the forward (by Jenifer Tidwell) to Theresa Neil's excellent Mobile Design Pattern Gallery
I think quoting it is well within fair use (and you can read it in Google Preview anyway. For inspiration's sake ...

To name something is to begin to understand it.

My five-year-old son, like many children, enjoys looking at clouds. A few weeks ago, he clued into the fact that different kinds of clouds had different names. And so, being of good geek stock, he proceeded to memorize them—cirrus, cumulus, stratus, cirro- stratus, cumulonimbus, altostratus, lenticular; all of the ones I knew, and then some. I’d certainly never heard of “cumulus congestus” before.

Now, when he looks at the sky, he can tell me which clouds are which. More than that, he notices more than he did before, and with greater nuance. He has learned to visually discriminate among cloud types based on texture, color, height, movement, and who knows what else. (They’re not always easy to tell apart, of course, but that doesn’t bother him.) He can predict, with some accuracy, which ones might drop rain on us and which won’t.

And in his limited preschooler’s fashion, he uses his cloud knowledge to analyze the big picture. “Cirrostratus clouds might mean a warm front,” he points out. Or, “Cu- mulus congestus might turn into cumulonimbus! Then we could get a storm.”

Above all, he enjoys knowing these names. Little kids seem to get a kick out of naming the things they love, whether they’re clouds, dinosaurs, bugs, cars, dolls, or movie characters. Certainly their imaginations aren’t limited by that left-brain knowledge, despite our grownup romantic biases—my son still sees palaces and ducks and cauli- flowers in the clouds, even as he names them “cumulus.”

So it is with us grownups. That brings us to the topic at hand: by recognizing and naming patterns in interfaces, we “see” those interfaces better. We notice more details, because our brains are more attuned to what we should look for. We can start to predict the workings of the software we use, because we know how certain interface patterns should behave. Then we can tell other people what we see via an expressive new vocabulary.

And how do we learn these patterns?

When my son learned about clouds, the best tool he had were pictures. Lots of pictures. After looking at some of these “catalogs” in books and websites, he learned to see rather subtle differences between cloud types, some of which are hard to describe verbally.

Likewise, the best way to learn interface patterns is to see visual examples. Now, I’m a writer, so I love words. When not restrained by courtesy, I would happily go on endlessly about what patterns are, how to choose them, and the differences between them! But it’s clear to me that anyone who simply wants to design interfaces—that is, anyone who needs to know patterns as one component of their craft knowledge—won’t really need all those words. For a given pattern, they need just enough explanation to “get it,” and then they need to see a range of well-chosen real life examples to solidify and internalize that knowledge.

In this book, Theresa Neil has pulled together a spectacular collection of pictures of patterns. I can’t imagine the work that went into this, having tried it myself—it’s no small feat to review this many mobile apps, see what works best in them, and gather up all these carefully catalogued screenshots.

For mobile interface designers, this book is a treasure. Read it straight through if you’d like, but more than that, use its examples to improve your own designs.

  • Use your own judgment about what works well in these examples, and figure out what may work best in the context of whatever you’re designing.

  • Use it as a sourcebook for design inspiration. I found myself admiring these screen- shots for design aspects that had nothing to do with the patterns themselves, such as icon design and color usage.

  • Use it to expand your knowledge of how existing apps work, without laboriously downloading and using them all (and on several devices, don’t forget).

    You might even go out and find your own pattern examples in the mobile apps you use daily. In fact, I’d bet that once you learn these pattern names, you won’t be able to avoid doing so. Having had my son point out “cumulus congestus” in the wild a few times, I know it well, and, gosh—I don’t know how I ever lived without that knowledge.

    Enjoy!
    —Jenifer Tidwell

 

Patrick Haller

unread,
May 11, 2012, 5:42:41 AM5/11/12
to hacker...@googlegroups.com
On 2012-05-11 01:20, Meng Weng Wong wrote:
> I am planning to write Startup Design Patterns, following in the
> footsteps of Christopher Alexander and the Gang of Four...

Which patterns? Business model, team organization, market development,
product development, something else?

Seems tricky to balance the readers of today with the readers of the
future. Future readers will be amused by some of the constructs because
they turned out to be stylistic period pieces, while today's readers
will want examples of what we see in the wild. [1]

A dry example but otherwise excellent balancing of these concerns (no
really [2]) is Myron Scholes' textbook on taxes:

http://www.amazon.com/Taxes-Business-Strategy-4th-Edition/dp/0136033156


Patrick

[1] or in Meng's Menagerie ;)

[2] The pace of tax changes increases with the scope of one's business,
so at a global level tax changes are not so glacial.
Reply all
Reply to author
Forward
0 new messages