DEV Community: Eran Kampf

Hard Truths About Entrepreneurship

Eran Kampf — Sat, 27 Jan 2024 16:43:18 +0000

I originally posted this on X as a response to this HackerNews post (full text at the end of this post) but thought its worth expanding on.

Too many people fall in love with the idea of entrepreneurship and all the buzz around it and confuse causation with effect - building somethign new and turning it into a successful venture is effing hard and most likely fail. If you just do it for a reward of being popular and racking up “likes” on your posts - you wont get far.

Or as Michael Arrington put it a long while back:

Entrepreneurs, though, are all screwed up. They don’t need to be rewarded for risk, because they actually get utility out of risk itself. In other words, they like adventure.

Anyway, here are some hard truths that need to be told:

3 failed attempts is nothing.
ProductHunt is useless BS echo chamber for fake “growth hackers”. Your customers aren’t there…
If you really verified your product “actually solved a problem” you’d have paying customers
You don’t need an “audience” or likes on your posts. Start with 5 customers from your existing network and figure out from there.
Don’t customers in your immediate social surrounding? You’re in the wrong space.
Find co-founders who can complete you and help build. If you can’t find anyone to join you, why would customers do it?
Indie hackers are not your customers.
But if for some reason they are - you chose a segment that is and doesn’t have a lot of capital. Think again…
You don’t need to “exist in the world of Entrepreneurship” you need to exist in your problem space.

Here’s the copy of the original post on HackerNews:

I’m writing this post because I’m done. I can’t do this anymore. After three failed attempts at building a successful startup and spending time institutionalized, I’m giving up on my entrepreneurship dreams. I tried everything - building an audience, making sure my product actually solved a problem, getting paying customers, and writing high-quality content and contributing to the community. But no matter what I did, I couldn’t seem to get anywhere. My efforts were fruitless and I’m tired of trying. I barely had 20 followers, my substack and product blogs didn’t get any signups, and while I did get a few upvotes (8) on Product Hunt once, I never had a paid customer. It was as if the world was against me and no matter how hard I tried, I couldn’t make any progress. I remember trying to interact and hype up my fellow indiehackers on Twitter, regularly engaging with their content, but no one ever paid any attention to me or followed me back. It was like I didn’t even exist in the world of entrepreneurship. And even when I did get some attention, it was short-lived and never led to anything substantial.

But it’s not just the lack of success that’s getting me down. It’s also the constant stream of digital nomad influencers on Twitter who sell extremely distorted, rosy, and often times false dreams to indie entrepreneurs like myself. They make it seem like building a successful startup is easy and anyone can do it with the right mindset and a few key tips. But the reality is that it’s not that simple. It’s fucking hard and it takes more than just a positive attitude to make it.

I know I’m not alone in feeling this way. There are so many other indie entrepreneurs out there who are struggling and feeling like they’ll never make it. If you’re one of them, I want you to know that you’re not alone. It’s okay to feel defeated and to want to give up. But please don’t give up. Keep pushing forward and don’t let the failures define you. There’s always a chance for success, no matter how small it may seem.

But for me, I can’t take it anymore. I’ve hit rock bottom and I have nothing left to give. To all the indie hackers, hacker news, and Reddit readers out there, please don’t be fooled by the false promises of digital nomad influencers. Building a startup is hard work and it takes time. It’s not as easy as they make it seem and it’s not for everyone. Don’t let your dreams consume you like they did for me, and PLEASE PLEASE PLEASE PROTECT YOUR MENTAL HEALTH AT ALL COST! Don’t make the same mistakes I did and realize that entrepreneurship may not be the path for you. It’s okay to admit defeat and move on to something else.

Golden Testing Helm Charts

Eran Kampf — Sun, 14 Jan 2024 21:00:00 +0000

We love tests at Twingate. When working on the Twingate’s helm charts repository I wanted to incorporate testing like we do with other code. For a long time our release process requires a long process of manual testing - every change to the chart’s templates required a manual process of testing the chart with various inputs to make sure it still works as expected. Enter golden tests as a way to automate this process…

What are Golden Tests? #

Golden tests, also known as snapshot testing, involves comparing the current output of your code with a “golden” reference or a previously stored correct version.

It’s a particularly useful method in situations where the output is complex and can change over time, like configuration files or templates.

Gold Testing a Helm Chart #

The concept is simple:

We maintain a directory of different helm input files (different permutations of values.yaml that we want to test).
For each such file we also maintain the expected output from that file. The expected output for running our chart with foo.yaml as input is stored in foo.golden.yaml
When we run our tests the simply render the chart’s result for every input file and compare the output with the content of the golden copy - if they’re different we fail.
When we want to update the golden copy we can run the test with an -update flag in which case, instead of comparing, it will write the output to the golden file. We can review the diff before commiting the test changes.

Here’s the code to run our tests:

package golden

import (
 "flag"
 "fmt"
 "os"
 "path/filepath"
 "regexp"
 "strings"
 "testing"

 "github.com/gruntwork-io/terratest/modules/helm"
 "gopkg.in/yaml.v2"
)

var update = flag.Bool("update", false, "update golden test output files")

type ChartYaml struct {
 Name string `yaml:"name"`
 Version string `yaml:"version"`
}

func GetChartYaml(t *testing.T) ChartYaml {
 chartYamlFile, err := os.ReadFile("./my-chart/Chart.yaml")
 if err != nil {
 t.Fatalf("Error reading Chart.yaml: %v", err)
 }

 var chartYaml ChartYaml

 if err := yaml.Unmarshal(chartYamlFile, &chartYaml); err != nil {
 t.Fatalf("Error unmarshaling YAML data: %v", err)
 }

 return chartYaml
}

func TestHelmRender(t *testing.T) {
 files, err := os.ReadDir("./test/golden")
 if err != nil {
 t.Fatal(err)
 }

 chartYaml := GetChartYaml(t)

 for _, f := range files {
 if !f.IsDir() && strings.HasSuffix(f.Name(), ".yaml") && !strings.HasSuffix(f.Name(), ".golden.yaml") {
 // Render this values.yaml file
 output, error := helm.RenderTemplateE(t,
 &helm.Options{
 ValuesFiles: []string{"test/golden/" + f.Name()},
 },
 "./my-chart",
 "test",
 []string{},
 )

 goldenFile := "test/golden/" + strings.TrimSuffix(f.Name(), filepath.Ext(".yaml")) + ".golden.yaml"

 // If error, we write the error to the golden snapshot
 if error != nil {
 output = fmt.Sprintf("%v\n", error)
 } else {
 // Replace `cn.chart` helper value with a stable value for testing
 // because we don't want to have to update all snapshots whenever Chart version changes
 regex := regexp.MustCompile(fmt.Sprintf("%s-%s", chartYaml.Name, chartYaml.Version))
 bytes := regex.ReplaceAll([]byte(output), []byte(fmt.Sprintf("%s-major.minor.patch-test", chartYaml.Name)))
 output = fmt.Sprintf("%s\n", string(bytes))
 }

 // If we were called with `-update` param - write `output` to our golden snapshot file`
 if *update {
 err := os.WriteFile(goldenFile, []byte(output), 0644)
 if err != nil {
 t.Fatal(err)
 }
 }

 // Read golden snapshot file and make sure its content is identical to output
 expected, err := os.ReadFile(goldenFile)
 if err != nil {
 t.Fatal(err)
 }

 if string(expected) != output {
 t.Fatalf("Expected %s, but got %s\n. Update golden files by running `go test -v ./... -update`", string(expected), output)
 }
 }
 }
}

You’d run this simply by running go test -v ./... or go test -v ./... -update if you want to update the golden copies.

An example of how we use this in Twingate can be found on the helm-charts and Kubernetes Operator repositories on GitHub.

Zero Downtime Django (gunicorn) Deployments on GKE

Eran Kampf — Sat, 06 Jan 2024 05:39:46 +0000

We recently switched to Twingate’s GKE load balancer to use Google’s new Container-native load balancer. The premise was good - LB talks directly to pods and saves an extra network hops, (with classic LB, traffic goes from LB to a GKE node which then, based on iptables configured by kube-proxy, get routed to the pod) and should perform better, support more features, and in general we’d rather be on google’s maintained side and not on legacy tech.

However, immediately after making the switch, we started noticing short bursts of 502 errors whenever we’d deploy a new release of our services to the cluster. We tracked it down to the following behavior described in the Container-native load balancing through Ingress docs:

502 errors and rejected connections can also be caused by a container that doesn’t handle SIGTERM.

If a container doesn’t explicitly handle SIGTERM, it immediately terminates and stops handling requests. The load balancer continues to send incoming traffic to the terminated container, leading to errors.

Why do we get 502s on pod restarts? #

The legacy load balancer relied on Kubernetes’s kube-proxy to do the routing.

kube-proxy configures the iptables on all the cluster’s node with rules on how to distribute traffic to nodes.

When the load balancer receives a request, it sends it to a random node on the cluster which then routes it to the pod (which might be on a different node).

kube-proxy is aware of the different pod’s states and when a pod changed state to Terminating it immediately updates the routing information.

With Container-native load balancing, traffic is routed directly to pods.

This eliminates the extra networking hop but at a cost that it is not aware of the pods state and relies on healthchecks to know when a pod is terminating.

We were getting these 502s bursts because once we deployed a new version, old pods were being terminated and when receiving SIGTERM they’d stop processing new requests. The load balancer, however, would still send them requests until healthcheck fails (it was set to 10s in our case) and it removes it from circulation.

To solve this we need to be able to gracefully terminate our pods - we need some sort of a toggle to tell the pod to start failing its healthcheck while it continues processing other requests regularly for enough time for the load balancer to stop sending traffic its way.

In order to address this issue, we must find a way to gracefully terminate our pods.

This requires some kind of switch that instructs the pod to begin failing its health check, while simultaneously maintaining regular processing of other requests for enough time to allow the load balancer to mark the pod as done and stop sending traffic its way.

To understand how to do this, lets first take a step back and understand Kubernetes’s process for terminating pods…

Whats the termination process for Kubernetes Pod

1. Pod is set to “Terminating” state

The pod is then removed from endpoints list of all services and kube-proxy updates routing rules on all nodes so that they shouldn’t receive traffic.

2. preStop Hook is called

The preStop Hook is a command executed on the containers in the pod.

3. SIGTERM signal is sent to pod

Kubernetes sends a SIGTERM to the containers in the pod to let them know they need to shut down soon.

4. Kubernetes waits for containers to gracefully terminate

Kubernetes wait for a specified time, called termination grace period for containers to gracefully terminate. By default, this period is set to 30 seconds but it can be customized by setting terminationGracePeriodSeconds value as part of the pod spec:

apiVersion: v1
kind: Pod
metadata:
 name: example-pod
spec:
 terminationGracePeriodSeconds: 60
 containers:
 - name: app
 image: busybox

5. SIGKILL signal is sent to pod and it’s removed

If containers are still running after the grace period, they are sent SIGKILL signal and are forcibly removed. Kubernetes then cleans up its objects store.

Gracefully Terminating Django (gunicorn) #

Gunicorn has its own definition for graceful timeout - when it receives a SIGTERM it will give workers a grace period (30s by default) to finish processing the current request they’re processing and exit. In our case we need gunicorn to continue serving requests for some time before shutting the worker down:

When pod is terminating, toggle health check (we’re using /health) view
Wait for 25 seconds (We set the LB to healthcheck every 5s and consider a pod down after 2 consecutive failures so 25s should give it enough time to fail)
Send SIGTERM to gunicorn

The simplest way to signal Django to start failing the healthcheck is by using a file - /tmp/shutdown - if the file exists we should start failing the healthcheck.

(We can’t use a variable and\or http call because gunicorn runs multiple workers and doing some multiprocess memory sharing magic is too complex)

So the detailed graceful shutdown process is as follows:

Kubernetes sets pod to “Terminating state”
Kubernetes calls preStop hook 2.1. Create a /tmp/shutdown file 2.2. Sleep for 25s - enough time for load balancer to refresh
Kubernetes sends SIGTERM to container and gunicorn shuts down workers

Our preStop hook is pretty simple: (Note that our LB are configured to healthcheck every 5s and remove target if it fails twice so we need to sleep for at least 10s to make sure pod is removed. These settings may differ on your system…)

lifecycle:
 preStop:
 exec:
 command:
 - sh
 - -c
 - echo "shutting down - $(date +%s)" >> /tmp/shutdown && sleep 25

Our Django healthcheck view:

SHUTDOWN_FILE = "/tmp/shutdown" # nosec

def is_shutting_down() -> bool:
 return os.path.exists(SHUTDOWN_FILE)

@internal_only_view
def health_check(_request):
 if is_shutting_down():
 return HttpResponse("Shutting Down...", status=503)

 ... Some extra healthcheck logic ...

 return HttpResponse("OK")

References #

External Application Load Balancer overview - Google classic load balancer vs. the new container-native ones
Kubernetes preStop Hook
Container-native load balancing

5 Tips for Choosing Your Startup’s Technology Stack

Eran Kampf — Sat, 31 Dec 2016 01:07:32 +0000

Having worked as a CTO and technology consultant to many startups I can tell you that choosing the initial technology is an important decision where you have to take into account several factors:

1. Prefer What You Already Know

Moving fast when working on a new startup is important. If the founding team is already experienced in a specific stack, its an advantage to choose it and work within their comfort zone rather then re-learn a new technology.

2. Consider The Problem Space

Sometimes the space your product is in dictates the stack.

Some technology stacks are specifically strong in certain areas (due to technical limitations, or just strong community) making them the go-to environments in those areas.

For example, if you’re writing an IoT embedded solution, a graphics engine or an AAA game you’d probably need C\C++.

Python, with libraries like Pandas, SciPy and NumPy (and a strong community around them ) is specifically strong solving computational problems like ones you’d find dealing with machine learning and data science.

Ruby has Rails and a community focused on Web Development.

And so on…

So its best to explore the problem space and see which tools and technologies are common and why before making a decision on your own stack.

3. Consider Hiring Advantages\Disadvantages

Using an obscure or an uncommon technology stack can make recruiting hard. You want to aim for a stack that’ll make it easy to recruit people.

Granted, good developers can learn any stack, but the question is, will the want to?

For example, if you’re writing a chat server in Erlang it’ll probably be a lot harder for you to find Erlang developers (or people willing to learn Erlang) over finding people proficient with Java\Ruby\Python…

4. Check the Community

When shit hits the fan you want to know you have somewhere to go — somewhere to ask question and\or get help.

When choosing a product to use I’d look at:

Any big names behind it as sponsors\users?
How active is the community? Is there a Slack channel\mailing list\public JIRA? are questions being answered on StackOverflow? are people writing about it in blog posts? (I’d look for pros\cons posts, comparisons to competing products and migration\success stories)
If open source — when was the last commit? is the code actively developed and maintained? Are the authors responsive to PRs?

5. Time to reach your first few milestones

As a startup, getting fast to market is your top priority.

It’s easy to fall into pre-optimization mode and forget you don’t have to support a Facebook scale just yet ;)

Figure them out a set of realistic goals and milestones and choose your technology accordingly.

You might be able to work just fine with a relational database instead of a complex NoSQL cluster.
You might be able to do just fine with a hosted service and avoid managing servers and deployments to a certain point in time.

It’s important to pick a technology that will let you get things done fast and meet your goals while not limiting your ability to scale or migrate to a better system in the future… (Its best if you can plan the roadmap to such a migration so you know where you’re heading)

For example, in one of the companies I’m working with, we started managing our data pipeline using Google’s Dataproc, which is essentially a hosted version of Apache Spark.

At our current scale we dont need a Spark cluster running 24/7 so using Dataproc we can schedule jobs that start a cluster, do their thing, and shut it off. In the future we’ll be able keep the cluster running on Dataproc 24/7 or even (since we’re using Spark which is open source) migrate away from Google’s service and manage our own cluster(s).

(Bonus Tip) — Watch out for The “Tech Stirrer”

Back in dapulse, we had a nickname — “Tech Stirrer” (sounds better in Hebrew) — for developers who’s always chasing the latest new fashion and keep trying to add new technologies to the stack and rewriting existing code without a real need…

The technology world is plagued with passing fashions. When consulting with friends and industry people you’ll always hear how you’re better off switching to the new latest and greatest.

There is no perfect technology. Everything has its Pros and Cons. Watch out taking advice from people who can’t see the cons…

Switch to a new technology based on specific advantages to your business rather than technology hype.

This post is an adapted and expanded version for my answer to How do startups typically choose a technology stack for their product? on Quora

How Do You Define “Good Code” ?

Eran Kampf — Fri, 23 Dec 2016 01:07:17 +0000

I was on a phone interview the other day where I was asked for my definition of “Good Code”.

The first thought that came to mind was maintainability — if it can’t be understood, maintained and extended by other developers than its definitely not good.

Then, other things came to mind: efficiency, elegance (simple, proper use of language constructs and environment capabilities), modularity, proper object-oriented design, …

Of course, and we tend to take that for granted, it also has to work… without errors, security holes, etc.

In his book, Code Complete, Steve McConnel supports my definition of good code as maintainable code:

Another theme that runs throughout this book is an emphasis on code readability. Communication with other people is the motivation behind the quest for the Holy Grail of self-documenting code.

The computer doesn’t care whether your code is readable. It’s better at reading binary machine instructions than it is at reading high-level-language statements. You write readable code because it helps other people to read your code. Readability has a positive effect on all these aspects of a program:

Comprehensibility

Reviewability

Error rate

Debugging

Modifiability

Development time — a consequence of all of the above

External quality — a consequence of all of the above

Readable code doesn’t take any longer to write than confusing code does, at least not in the long run. It’s easier to be sure your code works if you can easily read what you wrote. That should be a sufficient reason to write readable code. But code is also read during reviews. It’s read when you or someone else fixes an error. It’s read when the code is modified. It’s read when someone tries to use part of your code in a similar program.

…

Making code readable is not an optional part of the development process, and favoring write-time convenience over read-time convenience is a false economy. You should go to the effort of writing good code , which you can do once, rather than the effort of reading bad code, which you’d have to do again and again.

On the other hand, Paul DiLascia, from MSDN’s {END BRACKET} column, provides a list of traits that good code should have:

Whether you code in C/C++, C#, Java, Basic, Perl, COBOL, or ASM, all good programming exhibits the same time-honored qualities: simplicity, readability, modularity, layering, design, efficiency, elegance, and clarity.

Simplicity means you don’t do in ten lines what you can do in five. It means you make extra effort to be concise, but not to the point of obfuscation. It means you abhor open coding and functions that span pages. Simplicity — of organization, implementation, design — makes your code more reliable and bug free. There’s less to go wrong.

Readability means what it says: that others can read your code. Readability means you bother to write comments, to follow conventions, and pause to name your variables wisely. Like choosing “taxrate” instead of “tr”.

Modularity means your program is built like the universe. The world is made of molecules, which are made of atoms, electrons, nucleons, quarks, and (if you believe in them) strings. Likewise, good programs erect large systems from smaller ones, which are built from even smaller building blocks. You can write a text editor with three primitives: move, insert, and delete. And just as atoms combine in novel ways, software components should be reusable.

Layering means that internally, your program resembles a layer cake. The app sits on the framework sits on the OS sits on the hardware. Even within your app, you need layers, like file-document-view-frame. Higher layers call ones below, which raise events back up. (Calls go down; events go up.) Lower layers should never know what higher ones are up to. The essence of an event/callback is to provide blind upward notification. If your doc calls the frame directly, something stinks. Modules and layers are defined by APIs, which delineate their boundaries. Thus, design is critical.

Design means you take time to plan your program before you build it. Thoughts are cheaper than debugging. A good rule of thumb is to spend half your time on design. You need a functional spec (what the programs does) and an internal blueprint. APIs should be codified in writing.

Efficiency means your program is fast and economical. It doesn’t hog files, data connections, or anything else. It does what it should, but no more. It loads and departs without fuss. At the function level, you can always optimize later, during testing. But at high levels, you must plan for performance. If the design requires a million trips to the server, expect a dog.

Elegance is like beauty: hard to describe but easy to recognize. Elegance combines simplicity, efficiency, and brilliance, and produces a feeling of pride. Elegance is when you replace a procedure with a table, or realize that you can use recursion — which is almost always elegant:

_int factorial(int n) {   
  return n==0 ? 1 : n \* factorial(n-1);   
}_

Clarity is the granddaddy of good programming, the platinum quality all the others serve. Computers make it possible to create systems that are vastly more complex than physical machines.

The fundamental challenge of programming is managing complexity. Simplicity, readability, modularity, layering, design, efficiency, and elegance are all time-honored ways to achieve clarity, which is the antidote to complexity.

Clarity of code. Clarity of design. Clarity of purpose. You must understand — really understand — what you’re doing at every level. Otherwise you’re lost. Bad programs are less often a failure of coding skill than of having a clear goal. That’s why design is key. It keeps you honest. If you can’t write it down, if you can’t explain it to others, you don’t really know what you’re doing.

So what are the most important trait for “Good Code” ?

Later on, it struck me — like anything when it comes to engineering, its about balance. When we write code we strive to find balance between complexity and simplicity by constantly evaluating the different tradeoffs we have to choose in order to get there.

Therefore, good code is code that strikes the right balance balance between all of the qualities mentioned above.

Think about it the next time you’re writing code or reading someone else’s…

Originally published at www.developerzen.com on June 26, 2008.

99 Ways to Become a Better Developer

Eran Kampf — Thu, 22 Dec 2016 00:59:55 +0000

I’ve encountered this post on my weekend reading — 91 Surefire Ways to Become an Event Greater Developer.

It contain a comprehensive guide linking to all sort of blog posts providing insights on improving your skills as a developer.

While the list is very long and sometimes debatable it does have some interesting pointers. If you do nothing else, delve into item #8: Learn Programming by Not Programming referring to the following post by Jeff Atwood.

The topic in question is why some developers outperform their peers regardless of their accumulated experience:

But the dirty little secret of the software development industry is that this is also true even for people who can program_:_ there’s a vast divide between good developers and mediocre developers.

A mediocre developer can program his or her heart out for four years, but that won’t magically transform them into a good developer. And the good developers always seem to have a natural knack for the stuff from the very beginning.

The answer lies in the quotes taken from Bill Gates remarks:

“The nature of these jobs is not just closing your door and doing coding, and it’s easy to get that fact out. The greatest missing skill is somebody who’s both good at understanding the engineering and who has good relationships with the hard-core engineers, and bridges that to working with the customers and the marketing and things like that.”

Eric Sink makes the distinction even clearer in You Need Developers, Not Programmers drawing a distinction between Programmers who are only excited about writing code and basically only care about doing that, and Developers who contribute to the software product in many ways.

The Great Programmer\Hacker Stereotype

You all know that guy (hell, most of us were that guy when we just started out, I know I was) — he has great technical skills, likes writing code and can spend hours within his IDE writing code that’ll make most of us scratch our head. Yet, he views the world only in one dimension — code. Business? that’s for the managers to figure out. Sales\Marketing? annoyances for others to take care of. Documentation? but the code is so obvious…Builds? Deployment? Configuration? …

Passion for code is a great quality. But as a specialist it’s all too easy digging yourself deeper and deeper into a skill you’ve already proven yourself to be capable at when you’d be better off using the time to cultivate other skills that are part of the process of making software — rendering yourself obsolete over time…

The great hacker is a one trick pony — he writes great code but that’s about it… Most of these guys end up working alone as consultants or freelancers where they don t have to care about that other stuff, or they end up as programmers at some big firms where there’s more room for specialists doing specific jobs (Architects to architecture, PMs do project management, Programmers code…). On the other hand, those who truly like making software, open up to the other aspects of software development.

When that change in mindset happens, that’s when you can truly grow exponentially…

So what do I do?

Ok, I guess you got the point… But how do you get started? Here are my own 5 cents on the topic…

Read, Read and Read Some More…

We’re in an industry that is moving forward at a fast pace. Technology becomes obsolete every year and a half or so and as developers. we have to constantly struggle to keep up. Books are not only great to help you keep up but also to expand your knowledge to other fields. There are plenty of interesting books and blogs about, well, pretty much everything.

Here are some recommendations to get you started:

Oh and one word about programming books: the best ones are timeless, transcending choice of language, IDE, and platform.

I try to stay away from them thick, heavy, language\platform specific references — most of them go out of date after a year or so anyway and most of the information there could be easily obtained elsewhere (online — Google, the product’s docs, blogs…)

Most programming big are just a waste of your time (and money…)

Contribute to an Open Source Project

Back in the days of Delphi, I was involved in Project JEDI dedicated to exposing different APIs (especially the Win32 API) to Delphi developers. I learned a lot working with the JEDI code base, documentation, samples and other team members.

Later when it was time to get drafted to the Israeli Army (we all have to do it at 18 here) the experience, credit, and code samples help me land a (very) exclusive position as a programmer. Who knows where I’d be today if I didn’t qualify and had to serve as a combatant…

Contributing to an open source project is a great way to gain experience, learn and get better.

There are no job interviews to pass, degree requirements or commitment to working hours or schedule required — you can just join in and start submitting patches or contribute in ways other than code (submit bugs, docs, support, …).

You can learn a lot just from studying the code and interacting with your peers…

Contributing to open source shows dedication and passion — it’s a walking talking resume.

Get a mentor

Find yourself a mentor or mentors who can teach you about different aspects of the business. I’ve had several at SAP and talking with them proved to be an invaluable asset (If you’re reading, thanks! :))

It doesn’t have to be official mentoring which is part of the person’s goals or job description. Many of your peers are experts in their field and they’ll be happy to show you around if you just show some interest…

Become a Mentor

Great developer are eager to learn… and teach. Can you pass you passion and knowledge to others?

You can also…

Open a blog about your experience, opinions, etc.
Start answering questions at stackoverflow.com and collect achievements

Land an Internship

Try getting an internship in a different role. When I was in SAP they had a special program allowing employees to apply for a ~6 months position somewhere within the company. The reason behind it was to get employees familiar with different aspects of the company. Maybe product management, marketing or sales in not really your first choice of profession but why not try it for a couple of months without the risk of going through a career change? How cool is that? I’m sure many large corporations has something similar and even if not, it can’t hurt if you come up with such an interesting offer to your boss…

Own a Product Area

Get ownership on some part of the product your team is working on.

Wether a specific component or a vertical (like Security) you should be in charge of getting it done — from getting the definition done with the product\sales\business team, through UX, development, QA, etc…

There’s nothing better than learning about the process of software development through experiencing the entire cycle…

Innovate

Start something new. When working on Duet we’ve had many issues getting the thing deployed. So I made a tool for (myself mainly) our QA and RIG (regional implementation group — the guys who work with customers) to help diagnose problems. This later became the official Duet Support Tool and got its own dedicated development time. Is your product, development environment perfect? I’m sure not… find a need a feel the gap…

Why? If by owning a product area you learned about the entire development cycle, here you’ll learn about defining and “selling” to the team…

Bonus Reading…

Another link worth visiting is the one about the Metrosexual Developer. Funny and true… 😉

Related:

So you want to be a great developer?

Originally published at www.developerzen.com on December 5, 2008.

5 Things I Learned About Managing an R&D Team

Eran Kampf — Wed, 19 Aug 2015 00:00:00 +0000

I made the first developer I was ever in charge of want to quit programming. That was roughly over 15 years ago. I’d like to think I’ve improved over the years…

I think a key moment to that development was during the early years of my professional career. I was working at a big software company, spending probably 12+ hours a day at work and not getting enough done. A lot of my time was spent on solving bugs and problems for other team members rather than making actual progress on product features.

One day one of the team leads pulled me aside and told me that, rather than going around fixing problems I should tutor people so that they could be more efficient and hopefully solve these problems on their own.

“Your time is limited.”, he said, “You can get much more done if you start delegating”.

That was my first “management lesson”. It got me thinking beyond the code and architecture of a particular project, about the team behind it and how to get it working effectively.

Fast forward by a decade or so, I’m still in tech writing software. I’ve worked in teams, I’ve helped teams as a freelancer and I’ve built teams as a CTO.

Mainly, I had tons of chances to mess up… and learn…

5 Things I Learned About Managing an R&D Team #

1. Let Go

Let go. You can’t do everything yourself. You have to learn how to delegate effectively and the first is letting go. When you become the bottleneck for decisions — your team becomes idle and unmotivated.

Developers turning managers often have trouble with this. It’s hard to pull back from the urge of doing everything yourself the way you see right, to trusting that responsibility to another person.

It’s also hard to factor out individual preferences when reviewing said work, to distinguish between “I would have done this differently” (usually “better” is there too) to “this is not done right and needs more work/rewrite/refactor/…”.

Recognize you can’t do everything. Close your eyes, fall backward, and learn to trust.

It’s worth it — you get much more stuff done, less pressure, and your team is better.

2. Be Agile

I worked at a company where they liked SCRUM. They really liked SCRUM. Everything had to be SCRUM. By the book. Every meeting, every procedure… to a point where it was counter-productive — you had to skew your development process to deliver SCRUM result.

You couldn’t, for example, split work between backend infrastructure and UI they’re separate systems requiring a different focus.

In SCRUM, “each sprint is required to deliver a potentially shippable product increment” which means you need to demo some half-assed “product” to a product owner (who represents a customer that doesn’t care about backend infrastructure and just wants his dashboards) on every iteration.

A team could not concentrate on having a solid backend before crafting a UI, it had to do both at the same time to meet the sprint requirements.

These guys were 100% “Agile”, but still missing on deadlines, under-delivering and burning out due to their process’s inefficiency.

By now you’re probably reading this story and saying to yourself “They just didn’t get SCRUM right”. Which is exactly the point — what’s “right”? who decides? is it the holy texts of some Book of Agile?

As a development manager, the #1 thing that should be on your mind is *“What can we change in the what we’re doing to be better?” *There was no one there asking this simple question.

There’s a subtle difference between doing agile , which is the simple practice of some methodology, and being agile which is outcome-oriented and feedback driven.

Be agile.

The process is not set in stone. It’s there to be personalized and constantly be tweaked & changed… You have to constantly adjust how things are done according to team feedbacks and lessons learned to keep it as an asset rather than a burden.

3. Run Efficient Meetings

Most meetings are crowded and inefficient. A lot of time is wasted on ops (scheduling and getting people in the meeting) and on syncing everyone up-to-speed which rarely leaves time to actually discussing actionable items and making a decision (which is also why meetings tend to stretch beyond their schedule).

Don’t waste time syncing people. Have that information ready beforehand so that people come ready.

Use tools like Monday.com and Slack to write ad-hoc updates. This way anyone can catch up on relevant topics without being called into a meeting. When people attend a meeting when they’re prepared you can skip the prolog and go straight to the issues at hand. For example: Weekly meetings can skip summarizing what everyone did the past week and focus on planning the next week.

The use of ad-hoc updates opens your organization’s information to more people than you would normally call into a meeting or add to an email thread. It also allows people to catch up on their own schedule. I’ve found people tend to be more up-to-date and engaged this way plus you get the benefit of not wasting time in meetings. So why not?

4. Streamline the R&D process!

The R&D processes and infrastructure are the heart of the team. If deploying a new release is hard — each new release will be a nightmare. If writing tests is complex — developer won’t write them, or waste a lot of time and effort on them (and be miserable writing the few tests they do write) and in any case, you’ll end up with miserable developers chasing your own tail with bugs on each release. If you don’t have proper monitoring and logging infrastructure you’re flying blind into combat…

Development Infrastructure requires constant care and incremental work. It’s also something most people outside R&D can’t really understand and appreciate… It’s your job to protect and grow it.

(Also… automate. automate. automate.)

5. People — just know your team’s strengths, weaknesses, and goals

A development team is somewhat like a sports team. It’s members each have their own strengths and weaknesses that you have to know and use. They also have their own personal goals.

… The reason these teams have been able to remain consistent winners despite high personnel turnover is that they have been able to combine a realistic view of the often temporary nature of the employment relationship with a focus on shared goals and long-term personal relationships.

Finding those shared goals is and working on them helps keeps you both engaged and motivated. When good people don’t feel like their moving forward with their own goals they lose motivation and eventually leave. It’s also great for hiring 😉