🧠 Resources to think like a developer

[nathanaelb]

Hello everyone,

It seems to me it may be helpful to have a background in coding, even when developing/building with Glide which makes developing accessible to people like me.

By “background”, I mean experience, but also an understanding of methods, algorithms, data structures and tables, use cases, how tech layers server side might work, the cost of calculations, etc. (I am certainly using the wrong terminology.)

My question is more focused on backend and data resources, since there are already quite a few threads in the forum on tools and design:

Could anyone recommend resources to help think like a developer? Maybe a simple book, or slides, or a video or two? Maybe a book that any junior developer needs to have read and mastered to apply for a job? A practical resource whose takeaways would happen to be applicable to Glide.

I’m not interested in a computer science course but I am interested in acquiring a few basics that would help me – and maybe others – with developing in Glide.

Thanks!

[Jeff_Hager]

Completely agree. Glide makes things much easier for non-technical people to get quick results, but a programming background does help with more complex methods. My day job is programming, so I think a lot of that background applies nicely when I apply those skills into Glide. Like you said, it’s not so much about knowing a language or how to program, but it’s about knowing how to think like a developer.

I think many programmers think very literally and are naturally problem solvers. I don’t look at a problem and wonder why it doesn’t work the way I think it should work. Instead I look at a problem and think about what I need to make it work the way I want. What are the fundamental rules of the platform that I am bound by and how do I work with and around those rules? There are some things in Glide that could definitely be better and easier, but with the exception of very few limitations, I always go in with the attitude that anything is possible. It may not always be easy, but in my 20 years of developing, I have yet to use a development environment that can read my mind and that doesn’t require some critical and creative thinking to get results.

I think the most important thing with Glide is to learn the fundamental rules of how the platform works and what you can and can’t do with it. Once you learn those rules, then everything else is a lot easier to get done because you don’t dwell on why something isn’t exactly the way you think it should be. Instead you think about what tools you have to work with, alternative ways to do the same thing, and learn a lot in the process…and when a new feature is added to the platform, then you can readapt as needed. There’s a million ways to do anything. Some ways may be more efficient than others, but in the end there is no wrong way to do something as long as it still gets the job done. You can always modify and tweak down the road once all of the piece make more sense in your head and you discover better ways to accomplish something.

Here’s a few resources that I found after a quick search. Hopefully they are generic enough to get you in the right mindset.

Hard Coding Concepts Explained with Simple Real-life Analogies

Coding Concepts

Basic Programming Concepts - Coders Campus

For me, to think like a developer, you need to break things down into small pieces. Looking at a problem as a whole can be overwhelming, and depending on complexity can be very hard to visualize. I like to work on small chunks and get the very basic structure of an app up and running. From there I start to build additional functionality piece by piece. That becomes the fun part for me. Getting started is the hard and a little tedious, but adding the fun stuff is where I get excited.

Another thing I like to do is work backwards. I know what I want my end result to be, but instead of thinking of the entire process to get there from the beginning, I like to start at the end. What tools do I have to work with…what do I need to get my result…ok, what is required to get the piece before that…then the piece before that. All of a sudden you’ve worked your way to the beginning and your entire function is finished. I debug software the same way. I start at the point of the error, then work my way backwards to find the source instead of looking at multiple potential sources and trying to figure out which one may be the problem…

I think the core of any programming language is the IF statement. Computers are binary. Everything is True or False, Yes or No, 1 or 0. Any IF statement will determine the path that a computer will travel through the code.

In general, computers do everything in order, or take a particular path. Just like reading a book, you start at the beginning and read to the end. The difference is that you can control which pages are read or control if something needs to be read again. If you are familiar with the “Choose your own Adventure” books, you could consider that a very basic version of programming logic.

As far as data, most software has a backend database. I generally like to think of a database as only a place to store data. Glide is a little different in that instead of a place to write code, they have computed columns that allow you to perform logic. In the end, those computed columns can be read like you are reading from a database, but you can’t update the data.

I know most of this is pretty generic, but hopefully some of it helps. Feel free to ask if there is something a little more specific you want to know more about.

[AyS_0908]

@Jeff_Hager

As far as data, most software has a backend database

Thank you a lot @Jeff_Hager.
Clearly, as a non developper, one of my key fears when starting an app are:

• do I structure correctly my database for my v1 features list?
• will it be appropriate for the v2, v3… features that I will want to add?

And much too often, the answer is ‘No’ to both questions! Need to redo everything from scratch…

Since then, when starting, instead of jumping into Glide, I define the User Stories and the macro database structure (with key fields and relations)
… I even made a basic app* for this

(* I wanted to share it but I am not confident in its…database structure !)

[Mark_Turrell]

I suspect we make major breakthroughs in our thinking once we have experience, even if we have been advised for or against a certain direction in the beginning.

My covid testing app has been totally redesigned 4 times. First, a prototype to essentially sell in my services to the client. Then a working run-through of what they wanted (at the start of April) led to them thinking about what they really wanted. At this point, in a traditional dev world, we would have had an environment setup, and still in the UX / CTO stage.

Then a period of rapid daily iterations on product features. “Could we do that?” and then a bit of technical exploration (maybe 15 mins… maybe a few hours" then a ja-nein answer (German client

Then the disaster. A working system… but super slow. Functionality was easy to break too. An intense few days of tears and discovery, and I realized that I had to throw out most of what had been done, and start with a completely new method.

What was wrong? I started by relying on GSheets to do everything. Then had two apps going against the same sheet. Cool… but slow. Then Glide Tables, writing in and out, adding rows, deleting rows, to keep track of what was going on (there are users - CollectUser - and people do tests - TestFlow).

I had to rethink how I did things, scrapping anything to do with deleting rows… and also moving far away from GS.

Now I have a system with 20+ medically trained experts doing video calls, moving into pilot this week, with an aim of 10,000+ daily corona tests done by video (on a Glide app). And doing the background work to move the app to SQL when the Glide side is ready (to handle 100,000 tests a day maybe).

And then… how to replicate the templates so I can have an app for various countries around the world (not available in the Glide Template store )

Again, if I compare this to traditional business app development, we would be 8 weeks in (so 4 x 2-week sprints). The Ukrainian dev company was going to charge 120K EUR for 12 weeks… and only build the user side of the app (so half the system). They would have gone mad with the client as the business needs changed on a near-daily basis (so hard to work). And the company had no business analyst, so very little inspiration or direction from the client (which is actually not good, because they might withhold payment if they do not like what they get). The company would not be ready to pilot in May (as we are) and very unlikely to be ready even in July. Plus they would have had to pay a lot extra to find a call center app - that would only have been managing things as emails…

Plus I found out 35% of my users will be on computers rather than mobiles (our original idea). The desktop / tablet functionality is ok (lots of wasted space), but it is better than nothing, and I could turn it on with a checkbox.

I could rebuild this app dramatically faster now, maybe in 3 weeks. I do not want to because I hope covid goes away and I can use the experience, and maybe some of the code tricks, for other projects.

I also started developing tabs (I use them instead of screens) to map out functionality before I really built it, to get user and business feedback early.

So many things learned… and so much more to come.

Big thanks to the whole community - and the Glide team!

[nathanaelb]

Thanks @Jeff_Hager and @AyS_0908 for sharing.

I looked at your resources Jeff and learned a lot. I ended up by searching for “coding concepts” on Youtube. The good: there’s a universe of content there. The less good: Youtube is a black hole

I also had a look at good ole books. What I’ve found so far. I’m leaning towards the first one, it looks fun. If anyone has feedback, don’t hesitate.

Grokking Algorithms: An Illustrated Guide for Programmers and Other Curious People

Introduction to Algorithms, 3rd Edition

Algorithms (4th Edition, Sedgewick)

Algorithmic Thinking: A Problem-Based Introduction (Zingaro)

Cracking the Coding Interview, 6th Edition: 189 Programming Questions and Solutions

[erwblo]

I interviewed Werner Vogels, CTO of Amazon, a few times. They were some of the most inspiring interviews I’ve done. Because he teached me how Amazon works doing product development. Doing development in general. But doing software development as well. I use this in almost every project I do and teach this to everyone I teach.

It goes a little like this.

Before you start building or making anything follow these 3 steps.

1. Write a press release. Write a press release as if the thing you are going to build is already finished. That helps you describe clearly what it is, why it’s valuable, to whom it’s valuable, etcetera. Why people need it. This helps you get your idea as clear as possible.

2. Write the FAQ. What are the questions people can have about your product? Write them and the answers down. This helps you to be clear and precise as well.

3. Write the User Manual. Write down how people can make most of what you’re making.

Only when you’re happy with that and have rewritten everything thanks to feedback of other people, you start building.

This has nothing to do with technique, but this is how a company with a lot of developers works

[nathanaelb]

@AyS_0908
Thanks, I will keep this in mind and use this.

[Darren_Murphy]

@erwblo

Write a press release. Write a press release as if the thing you are going to build is already finished. That helps you describe clearly what it is, why it’s valuable, to whom it’s valuable, etcetera. Why people need it. This helps you get your idea as clear as possible.

I was at AWS Re-Invent in Vegas a few years back, and attended one of their Product Management sessions (my background is software development/product management). This idea of writing the press release when the idea is conceived is the one thing that really stuck in my mind from that session. Such a novel approach, but really makes a lot of sense.

[erwblo]

Yeah I do it all the time myself. And with that press release I start validating my idea. I ask people: what do you think, what do you miss, would you use this? And this is valuable wherever you work.