AktaryTech

3LL #3 (go here to start at the beginning: http://ow.ly/2EAj50OsFPQ)

Project: build a web3 solution to create limit orders on Uniswap (v1, before this functionality was native to Uniswap)

3LL:
- don’t build a product that is fundamentally a single feature for someone else’s product unless you’re certain they will never implement that feature.

- we had trouble managing budget and scope on this project. The requirements were loosely-defined when we signed the contract (as is often the case), but we didn’t do a good job controlling scope and expectations as the project progressed. As a result, we ended up with a “balloon payment” of scope as we neared the delivery deadline. This resulted in long days and nights, burning out our resources unnecessarily. Make sure to checkpoint on both delivered code and upcoming expectations and don’t be afraid to push back as the project progresses.

- accepting payment (even a portion) in anything other than cash is a riskier proposition than you may think and may introduce unforeseen dynamics. We accepted a portion of payment for this project in the project’s token, which seemed great when the price increased. However, dev teams are often subject to a lockup period when they cannot sell. Even if you’re not, you don’t want to be dumping your client’s token, lowering the price and signaling a lack of faith in the project. Thus, you’re in for the long haul and this has historically been a bad position to be in, in both crypto and startup equity. Make sure you’ve covered both your costs and a reasonable margin *in cash* before assigning any value to the token/equity.

David Aktary on LinkedIn: 3 Lessons Learned (“3LL”) from building custom software for clients… 3 Lessons Learned (“3LL”) from building custom software for clients #1 This is the first in a series of bite-sized, bulleted posts that I hope will help my…

3 Lessons Learned (“3LL”) from building custom software for clients #1

This is the first in a series of bite-sized, bulleted posts that I hope will help my readers avoid the pitfalls of building new software, either in-house or with a dev shop. I’ll be posting these on a retrospective project-by-project basis. Please let me know if there are specific topics you’d like me to touch on. Now, on to it…

Project: build a web3 front-end for a blockchain protocol that was looking to expand to a new blockchain.

3LL:
- when extending an existing, evolving product, timing is critical because you’re not only dealing with peeling the onion of requirements on your project, you also have to ensure those requirements and what you build align with the existing, evolving code base.

- it is critical to engage the product owner (yes, singular) and keep him/her engaged throughout the project. It’s very easy for engineering to do a show-and-tell occasionally and, if the product owner is in a passive mode and/or otherwise distracted, keep moving the wrong direction. Both engineering management and the business need to ensure the pressure stays on at this interface point.

- if you’re an indie developer or a small dev shop, be aware that when you sign a client, you’re exposing yourself to risks you may not see coming so make damn sure your contracting, invoicing, etc. is air-tight. In this project, our client team split from its parent org right as the project was wrapping up. The parent org reached out asking us to refund a large portion of what they had paid us. It was a miscommunication between the two client sides and was resolved ok, but if we didn’t have documentation, we could have been in a bad place. Keep pristine records and paper everything.

The last live webinar for DSU 101 is this Wednesday, 6/14, at 5:30pm CT! Sign up and view past recorded webinars and get ready to learn how to grow solo in your development career!

Use code DSUFB for 40% OFF!
www.devshopu.com

Dev Shop U Whether you’re a fresh bootcamp grad, a developer working 9 to 5 and dreaming of going independent, or an established software consultant, there are many aspects of opening and running a development shop that you can’t learn without help or experience. We’re here to help you with that.

At learning how uses to build and apps

JavaScript has become the most common language for implementing interactive web pages; this Stanford Professor agrees.

https://medium.freecodecamp.com/stanford-just-abandoned-java-in-favor-of-javascript-for-its-intro-cs-course-fe40543e81d8

Stanford just abandoned Java in favor of JavaScript for its intro CS course. The Stanford professor who wrote a popular book on Java — and has taught Java for 15 years — is now abandoning Java in favor of JavaScript…