I have always loved the C programming language. I remember being a young programmer (man that was 15 years ago) when I wrote my first C program. It seemed like absolute magic (and it still does).
Since then, I love (re)discovering the language every chance I get.
I found this post incredibly well done with some great examples. I wish we had resources like this "back in my day”.
Over the past few months, I have had the pleasure of working on a DApp called thisorthat.io built on the Ethereum network. It has been an absolute blast. I have had so much fun building the smart contracts as well as the React front-end interface.
I truly believe there is a huge future here, and it can be especially lucrative for developers/startup teams. If you look at Dapp Radar, you can see that many of the top DApps have less than 1,000 DAU (daily active users). If you consider how much money is being made, crypto-users end up being much more valuable than users on any other platform.
Take for example, Crypto Kitties. It's basically a mix of Beanie Babies and Tamagatchis. According to DApp Radar, 380 ETH (or $255K USD) has moved through their platform in the past 7 days with only 652 daily active users!!!. This is absolutely insane.
It's not all sunshine and rainbows though. After spending 80+ hours working on a crypto-centric app, I believe I have some insight into some pain points that will need to be solved before these types of apps are to be widely adopted.
In my next post, I will discuss some of the hurdles preventing DApps from going mainstream. There is so much room for improvement and innovation in this space, I feel that all devs should be looking at crypto like we looked at mobile dev in 2008.
To the moon!
tl;dr: micro.blog is pretty cool.
I have recently been thinking about my process of blogging / tweeting / facebooking / etc.. and have realized that I’m burnt out on all three. I LOVE to write. I started one of the first successful iOS Blogs, published numerous (software development books)[http://manning.com/trebitowski], and have been blogging since 2008. Here are a bit of thoughts about the various platforms and ultimately my solution.
Having over 4,000 followers on Twitter I used to find tremendous value in the platform. There was a time when I would ask a programming question and get 20+ responses within 10 minutes. I’m not sure if legit people have stopped following me or have stopped using the platform, but I am no longer getting any engagement. I probably have like 20 followers and 3,800 spam bots at this point.
To me, blogging has always had to be long-form. Maybe it’s just my wannabe Tim Ferris mindset, but this has held me back from writing for quite a long time. I would wait until I had a long (usually 1K words +) post before writing anything. So, it other words, perpetual writers block.
Don’t even get me started. I jumped on the #deleteFacebook bandwagon months ago.
Recently, I discovered Manton Reece’s new platform called http://micro.blog. I guess the platform isn’t necessarily new as he launched in 2015, but after using it, it still feels like it’s in the new/exciting phase.
Manton describes perfectly why he created the platform here and this captures my thoughts exactly on the content-creation ecosystem.
Here are some things that I’m super excited about the micro.blog platform:
- You post to your own site, keeping all the content controlled by you
- You can also pay $5 monthly for a hosted blog. This means their business is built on an actual product rather than advertising revenue.
- It’s built on RSS. I have always been a huge RSS fan and am glad to see a resurgence.
- It’s full of developers that I already know/admire. Guys like @manton, @collin, and @gruber.
- It’s incredibly social. The platform really encourages conversation.
- No follower count. This is arguably the best part. No one (including yourself) can see your follower count. This allows you the feeling to just create and not worry about the vanity of the whole thing.
I still plan on using Twitter to some extent, but my primary source of content publishing will/should be this blog. It will become a mix of my long-form posts and my “tweet-sized” snarky comments.
If this sounds even slightly interesting to you, def check it out and follow me on here or on micro.blog.
In 2008, I was still in college. I had just landed my first job with a small consultancy as their first iOS developer replacing their outsourced Ukrainian team. Within my first week on the job, the CEO asked me to jump on a sales call as the technical lead. This absolutely terrified me. I remember doing things like ensuring that I had a full glass of water so my throat wouldn’t get so dry (it still did). I also stumbled over my words, almost costing the team many sales. Eventually, I learned.
Since that day, I have taken hundreds of software sales calls. Each time trying to improve my process by testing out what works and what doesn’t. Now that I run my own company, I have found that one of the most beneficial things that I have done is implemented a standard call flow.
There is a reason that call centers require their employees to memorize call flows. When you have a call flow in place, it does a few things.
1. It allows you to practice and refine your pitch over and over again.
Practice makes perfect. Definitely cliche, but it makes a lot of sense here. As you give your pitch over and over again, you will start to pair it down to something that works for you and your team.
2. It builds confidence
Many people are nervous speaking to strangers. Software developers are no exception to this. As I mentioned above, I was terrified on my first few sales calls. This had a lot to do with the fact that I was ‘shooting from the hip’ and just trying to make things up as I went along.
Once I finally got a script in place, I was able to lean on it during future calls. This gave me the confidence that I was gathering all of the right information and representing myself in the best way possible.
Now when someone says “Could I see an example of your work?”, I can quickly shoot them a link or list rather than nervously trying to get the words out “well…uh…I made an app about catz, and I’ll find the link and…uhhh… send it to you later…”.
3. It’s so easy a ‘sales guy’ can do it
This is the part that I’m starting to experiment with. I want my pitch for my company to be so tight, that I could give it to any ‘sales guy’ to deliver and him represent Pixegon in much the same way I would. I have already done this with some of my engineers as I don’t always have time to make every single sales call and it has proven to be a huge success.
4. It removes emotion
This is a big one. When we are nervous, we tend to say dumb things. I remember a few times on sales calls when I was nervous (often because I really wanted/needed the contract), that I would seriously compromise on my rate just because the client suggested it. Had I had a call flow in font of me, I would have been better prepared to field such a request.
I now replace emotion with process and it usually ends up better for both parties.
Here is a rough outline of my sample call flow:
- Client Introduction - Ask the client about their background
- How did you find us? Good to find out what advertising channels are working
- Give my background - This is to establish credentials so they trust me
- Ask the client to give a 10,000’ overview of the project - Be careful here, they love to get in the weeds
- The 3 most important questions
- What’s your budget? This will let you know right away if you want to continue much further based on your budget tolerance and rough guess on how much the above will cost.
- What’s your timeline? Every single client will say ASAP. But really this is to find out if there are any conferences, holidays, etc… that are hard deadlines for them
- How are you funding this project? Self, Company, VC, Family, Startup, etc… This will also help you assess risk.
- Ask more detailed questions about the project (If timeline / budget are somewhat ok). Determine things like backend requirements, UI/UX, Staff aug vs full solution, etc…
- Don’t give them a $$$ estimate. They will usually ask you and it will usually cost you in the end if you give them a number here.
- If all goes well, ask them to send over any assets/wires/requirements and tell them you will follow up with a rough scope and estimate. Again, don’t estimate on this call
- Thank them for their time and let them know you will be in touch.
This is definitely a good starting point. Sometimes I will copy and paste these flows into a new document and tailor them based on the client that I am about to speak to.
Sales is something that I am constantly working on and refining. I hope to continue to share my findings with you as I learn along the way.