We’re doing a webinar on MongoDB on Oct 30, 2009 noon EST. It’ll be an overview of MongoDB & will also have Ian White from Business Insider talking about how they are using MongoDB in production:
Details & register at: http://mongodb1.eventbrite.com/
(The webinar is FREE)
We’ve been speaking about MongoDB at physical events like conferences and meetups. But since there’s interest in MongoDB from many different geographical locations, we thought we’d also do a webinar. This will be an interactive live web event. Look forward to seeing you there!
If you have questions on the webinar or have ideas for other such webinars shoot us an email at email@example.com.
Databases Should be Dynamically Typed
Software developers often debate the pros and cons of static versus dynamic typing in programming languages. Yet what about databases? Of course, static typing is traditional for databases. In a relational database we usual declare our columns and the datatype of each column’s values. However, we now see in the nosql space what are known as “schemaless” databases. Technically these products are often have some schema: for example in MongoDB we define collections and indexes. However, we do not predefine the structure of objects within those collections – they may all be different, or all the same. The typing is dynamic. Dynamically typed databases are a good fit with dynamically typed programming languages. It certainly feels like it would be a win to have a dynamically typed db when using a dynamically typed programming language (Ruby, PHP, Python, Erlang, …) How suboptimal it would be to have all the flexibility of dynamic typing in our code, and then hit a “brick wall” when we go to persist the data and have to statically spec everything out! There is synergy to be had between the dynamically typed programming language and the dynamically typed database. Dynamically typed databases can be a good thing when using statically typed programming languages. The best thing about static typing with compilers is that errors are reported at compile/development time. This is a big win for statically typed languages such as Java and C++. However, even with a statically typed database, type matching errors storing data are only reported at runtime! (That is, our java compiler doesn’t check our MySQL schema.) Thus some of the power of static typing in programming is lost at the storage layer. We still retain some benefits: assurance of some consistency to the data stored. But any failure to honor such a contract is only reported at runtime. Thus, it is more than worth considering using a “schemaless” database with say, Java, and getting out of the business of writing data migration scripts with each release. (Yes, some of that work stays but we can eliminate the majority.) Relational databases could be dynamically typed. While existing RDBMSes are statically typed, this is not an inherent limitation of the relational model. One could imagine a relational database with tables where one can dynamically insert a row with an extra column value at any time, and where values of cells in the same column of a table may have different types.
The Rise of the Strategic Developer
The work of developers is sometimes seen as tactical in nature. In other words, developers are not often asked to produce strategy. Rather, they are expected to execute against strategy, manifesting digital experiences that are defined by the “business.” But that is changing. With the automation of many time-consuming tasks -- from database administration to coding itself -- developers are now able to spend more time on higher value work, like understanding market needs or identifying strategic problems to solve. And just as the value of their work increases, so too does the value of their opinions. As a result, many developers are evolving, from coders with their heads-down in the corporate trenches to highly strategic visionaries of the digital experiences that define brands. “I think the very definition of ‘developer’ is expanding,” says Stephen “Stennie” Steneker, an engineering manager on the Developer Relations team at MongoDB. “It’s not just programmers anymore. It’s anyone who builds something.” Stennie notes that the learning curve needed to build something is flattening. Fast. He points to an emerging category of low code tools like Zapier, which allows people to stitch web apps together without having to write scripts or set up APIs. “People with no formal software engineering experience can build complex automated workflows to solve business problems. That’s a strategic developer.” Many other traditional developer tasks are being automated as well. At MongoDB, for example, we pride ourselves on removing the most time-consuming, low-value work of database administration. And of course, services like GitHub Copilot are automating the act of coding itself. So what does this all mean for developers? A few things: First, move to higher ground. In describing one of the potential outcomes of GitHub Copilot, Microsoft CTO Kevin Scott said, ““It may very well be one of those things that makes programming itself more approachable.” When the barriers to entry for a particular line of work start falling, standing still is not an option. It’s time to up your strategic game by offering insight and suggestions on new digital experiences that advance the objectives of the business. Second, accept more responsibility. A strategic developer is someone who can conceive, articulate, and execute an idea. That also means you are accountable for the success or failure of that idea. And as Stennie reminded me, “There are more ways than ever before to measure the success of a developer’s work.” And third, never stop skilling. Developers with narrow or limited skill sets will never add strategic value, and they will always be vulnerable to replacement. Like software itself, developers need to constantly evolve and improve, expanding both hard and soft skills. How do you see the role of the developer evolving? Any advice for those that aspire to more strategic roles within their organizations? Reach out and let me know what you think at @MarkLovesTech .