Pick a bug that affects you in open source software you use but never touched, dive into the codebase, fix the issue and contribute back. Now repeat for another issue on the same codebase, but one that doesn't affect you.
As a manager, I actually really like working with devs that just put their heads down and churn through tickets. My focus is trying to implement the business strategy and having developers that allow us to execute by building what is needed is excellent.
Developers (and I include myself in this bucket as I am 1000% guilty of it) are very easily distracted by The New Shiny, and sometimes it's irresistible to dive off into rabbit holes under the guise of 'learning new things'. Too many times I've ended up with massively over-engineered solutions that use experimental stuff that adds business and/or operational risk.
I know how soul-destroying it is to simply sit there pulling ticket after ticket though so I carve off time explicitly for self-directed learning & [what I hope are] fun little skunkworks projects. My goal is to try to find a balance between executing business strategy and continual improvement and development (heh) of my team.
But your solution sounds awesome. I would love my team to get more involved in open source projects & might suggest this as something to do as part of their usual workload. I wish I'd spent more time doing this when I was more actively programming myself.
Some potentially useful advice below. Remember to apply it to all the software you use, including operating systems on local machines, company infrastructure, things you deploy in the cloud etc.
Possibly your team has added workarounds and technical debt to your codebase for issues in your dependencies, that is probably a good place for them to start. It is also nice to give back to projects by working on "papercuts"; things that are easy to fix but annoy lots of people (Ubuntu did this for eg). Working on bigger stuff is good too, like fixing all crashes or adding important features from the roadmap etc.
Some companies have a "20% time (or X hours) on open source" policy, which is great for the sort of issues mentioned above.
Some open source projects have a list of ways companies can support them with resources (like sponsorship, download mirrors etc), for example here is the one for Debian:
It is a good idea to reword your employee contracts to mention the company policy on open source and give employees copyright over their contributions to open source projects. Some projects like Samba do not allow corporate copyright ownership. For other open source projects, having a diverse copyright holder base of individuals and a broad contributor community helps protect projects (at least those that are copyleft) from license and other changes brought on by company acquisitions, industry competition and other corporate influences.
If you want more separation between your company software and open source software, an Open Source Program Office or just an internal "open source team" is a good idea, although it is always a good idea for lots of folks to have open source experience, so rotating other employees through the team for periods/percentages of time might be good too.
When setting up an internal "open source team", the FOSSjobs website and the other job aggregators linked from the FOSSjobs resources wiki might help you hire new open source folks.
> Some companies have a "20% time (or X hours) on open source" policy, which is great for the sort of issues mentioned above.
We have this as an unwritten policy at the moment (... that I have been trying to get formalised for a while & need to follow up!).
> It is a good idea to reword your employee contracts to mention the company policy on open source and give employees copyright over their contributions to open source projects.
This is an excellent idea - thanks.
> If you want more separation between your company software and open source software, an Open Source Program Office or just an internal "open source team" is a good idea, although it is always a good idea for lots of folks to have open source experience, so rotating other employees through the team for periods/percentages of time might be good too.
We are not quite big enough (yet) for this, but something like this is already on our radar. We have a pretty major dependency in our stack that is starting to look a bit abandoned & have been idly discussing the possibility of hiring someone to maintain it.
Your definition of pragmatic programmer seems to be different from mine. In the classic book The Pragmatic Programmer [1], a pragmatic programmer is described as someone who knows their tools well, learns continuously, writes clean code, etc. I don't think going into depth contradicts any of these traits.
Regarding your question, why not find a new job / role? For example, I was curious about VR but knew nothing about it. So I got a VR gaming company to hire me as a freelancer at a much reduced rate for a few weeks. It was a great way to delve into the technical aspects of the space. Alternatively, you could start a hobby project where you go into depth.
Rather than assuming a definition, lets try to figure out what it means, ey.
adjective: pragmatic
dealing with things sensibly and realistically in a way that is based on practical rather than theoretical considerations.
In the context of programming this implies reaching for a ready made solution rather than re-inventing the wheel, avoiding implementing unused features, not spending time fighting code formatting and so on.
I think OP's closer in literal meaning to be honest, though missing a 'too' or something.
However, as GP points out, it's such a recognisable phrase with a slightly tangential or at least specific meaning that OP's question probably isn't quite what people expect (or they don't know what to expect) from the title.
Pragmatic usually implies a certain down-to-earth personality, but there's no contradiction in being pragmatic about something abstract and long-term. Our goals are all irrational or based on emotion in some way, but we can use "logical" strategies to move towards them.
I haven't read the book but when I think about pragmatic programmers I think about someone who takes the easy and simple route to some challengs. Not to be confused with naive solutions, or maybe intentionally naive in the moment and have a look at it later when other things are more clear.
Given the definition you wrote, what's the difference between a pragmatic programmers and an experienced one?
Instead of using a middleware between a web server and an application, write one (of course it was easier when I did it in 1994.)
Instead of using an IDE that magically recompiles Java and brings you to the errors, write the code that monitors the file system and runs javac, etc (2005).
Instead of using a CMS, write one (did it in Perl in the 90s.)
Instead of using a JS framework, write one (I kind of tried but no time for it.)
You'll find something that's relevant today and for your work.
There is no need to go on for too long because this approach is good for learning but bad for productivity. The problems to solve and the plausible solutions get clear pretty soon. The problem, as always, is the time.
I cannot support this advice enough. I recently did this with an exchange/order-filling engine in Go and it was a great little toy project. You’ll learn a ton about some things you don’t typically get to dive into when you take the “first principles” approach.
Honestly, I was just reading crypto news about an exchange one day and thought “that would be an interesting problem to tackle” and so I went for it. I have been meaning to post that to HN for a few weeks now, tbh.
I don't understand why it seemingly doesn't bother more people, always feels like that 'there are dozens of us!' meme when something like this is posted here. Scrum is depressing, it makes miserable factory-like work (or makes miserable factory-like work unapologetically transparent, perhaps). I can't think of any other profession that it wouldn't shock me to hear they work like this.
Companies that are very Scrum focused aren't actually all that common in my experience. If your job is depressing because of it, it may be time to look around. Remember to ask how the new place does things, so that you're not stuck with more of the same.
Not in the sense of 'scrum masters' and certification and all that - that sounds bad but in a different way and I've never experienced it. I just mean 'sprints' and 'tickets' and 'points' and 'stand-ups' really. (Which I assume isn't what you're saying isn't that common, certainly seems it from.. HN I suppose.)
How much time are you spending on these artifacts? Sprint planning and 'tickets' should take at most a few hours a sprint for developers (my effort is much higher, of course), standups are 15 minutes a day, points are just estimates.
I've worked, briefly as a contractor, in one these places before: full day sprint planning, 3 hour retrospectives, 1-2 hour standups, breakdowns of simple stories into sub stories etc. etc. ... but I didn't blame scrum and points for the fact I was miserable.
I think your point is kind of what I was alluding to with the 'or makes it [i.e. it exists without it] unapologetically transparent' parenthetical?
Certainly it's not 'scrum' per se that bothers me - I was carefully not saying 'agile' because I think that's fine it's just the typical method of 'doing it' that I meant, but seem to have fallen into a different trap in the process - but it is the breaking down of the job into actionable work pieces, 'tickets', and some of the ceremony around that, whether strictly 'scrum' or not.
But that's just me right, obviously some (lots of) people like it! My initial comment was that it's surprising (to me) how few seem to not like it, so I'm perfectly aware that's just my (and some few others') opinion.
> But that's just me right, obviously some (lots of) people like it! My initial comment was that it's surprising (to me) how few seem to not like it, so I'm perfectly aware that's just my (and some few others') opinion.
I guess it's a continuum ... I have people on my team right now that are working on a single story, other people who have a few dozen this sprint. If your team is breaking down what would be a single story on my team ... I could see that being annoying.
Now, the developer working on that story has a breakdown of tasks that they are managing as sub items in the story, but that's not getting managed with story points or any other heavy weight system.
It's not really about the time it takes for me, it's the division of work into tiny boring pieces, such that they often feel like they're taking as long to discuss & 'estimate complexity' (don't get me started - we don't have 'capacity' for a certain 'amount of complexity' within a.. two week period, so stop pretending it's not a time estimate - anyway..) as they would to do.
I'm reminded slightly of an article submitted here recently - https://martinfowler.com/articles/bottlenecks-of-scaleups/03... (though they're not really discussing motivation as such) - it's the detachment of engineering from product, I suppose. Little 'ownership' of or time to spend on thinking about the product experience, just 'do this', 'add that'. If I compare to people I know in other professions - accounting, doctors, tax - they all work more directly with a client or case, manage their own work. Of course they have managers too, but that relationship is more like 'I need some help with this problem that has arisen, let me now brief you on what I've been doing because otherwise you have no context' or longer-term performance etc. - not 'what tiny thing(s) did you do yesterday and which tiny thing(s) will you do today' every bloody morning.
This is only useful if you want to ship changes iteratively. If you're working a on a big blob of a thing that can have waterfall-style estimation and delivery then you'll avoid all that.
> it's the detachment of engineering from product, I suppose
This is more likely the cause. The emergence of product as a ruling class over engineering is a problem. Product is a useful concept, but I think we've all assumed only a person with a Product job title can be a product owner in a team, when I think Product adds much more value as a slightly more distant integration point for engineering, marketing, sales, customer support, legal, etc.
> I admit I miss the days when I could have spent weeks working on a project without being interrupted by daily "agile" meetings.
I think if there's no team you need to talk to very often and you're working in a pretty static environment then you should be fine. It's just that a lot of those nice problems are harder to come by these days.
> I just mean 'sprints' and 'tickets' and 'points' and 'stand-ups' really. (Which I assume isn't what you're saying isn't that common, certainly seems it from.. HN I suppose.)
Those are not common in my experience either. Perhaps I've just avoided working at depressing places :-)
I've never worked somewhere which actually named things 'stand-ups', 'points', 'stories', 'retros', or even 'sprints'. I'm familiar with the concepts, both from general reading, and thanks to someone who taught me all about Scrum, which was enough to put me off both Scrum and it's perverted form of Agile. If I hear those things mentioned in an interview, I soon have more questions, because there's "good Agile" and "bad Agile".
Sprints have occurred, in that there have been places with regular meeting and review cycles. That can work really well, imho. But even then, from the sound of it I've avoided the kinds of places where people feel under constant 2-weekly pressure to count up story points and highlight competitive ticket metrics.
I have a feeling I'll be starting at a place like that soon though. They use Jira, require a ticket for every PR, and by the sound of it are doomed to take a very long time to do anything. The tickets are written for accountability and reporting every change to management, so not written for developers. The approach smells like an anti-pattern to me. I don't expect to stay long; it's just a contract. I wouldn't choose a place like that for a long-term position, but I'm looking forward to the experience to find out what it's like with an open mind. I was hired as an interim team lead, but politics already changed what the role is since signing, and it's also been made clear that TLs there don't get to decide how anything is actually done. We'll see. I tend to bring new energy to a system.
> Scrum is depressing, it makes miserable factory-like work
I've used scrum while building cool VR tools for Architects, my Research Scientist was developing new algorithms and we were building stuff like real time collaboration with view tracking and hot spot overlays, all in a scrum framework.
This is like saying "office chairs makes miserable factory-like work", Scrum is just a management tool. If your manager is making your life miserable, that's not scrums fault.
Because most people are OK with getting a generous paycheck every two weeks for work they don't find too stressful. They can have fun outside of the 9-5.
What has scrum got to do with it? You can still have month-long tasks that are broken down. You just need scrum masters/product owners/managers who accept this as a viable way of working. We certainly do. Also, stories spanning multiple sprints also happen. It's always just a question of assigning resources efficiently and planning the tickets properly.
/e: also I'm very interested in what your specific "anything else" would be.
Basically, nothing in SCRUM helps empowering the grunts outside their own bubble, but SCRUM gives a lot of feel good things for management to expect from the bubble of grunts.
It does nothing to solve fundamental issues inherently. But these fundamental issues are well known, so any method not addressing them is rather weak by default.
Hm, I don't agree and see no real arguments here, sorry. I'll move on then, but thank you for the comment! I really hope you find the working environment you thrive in.
A slightly exaggerated point of view: but in a way, the problem with Scrum and Agile is that they have been appropriated by non-tech people because tech is where the money is at. If it wasn't Agile, it would probably be something else.
I know "but that's not agile" is a tired meme at this point, but if you read something like for instance the pattern work by guys like Jim Coplien and Sutherland [1], then Scrum as outlined by these communities of practices sounds pretty sensible. Just some random excerpts:
> Use Small Teams of people working on serialized work rather than striving for false parallelism.
> The Development Team organizes itself to get its work Done. The Development Team is solely responsible for how it does its work.
> Explicitly allot time for interrupts and do not allow more work than fits within the allotment.
> Create ad-hoc “birds of a feather” groups for each area of significant enterprise core competency or developer interest, where interested parties can trade notes on technologies, domain knowledge, and processes that are key to enterprise advancement.
The short answer is get a job that is actually interesting. I'm sad to say that - IMHO - software engineering as a profession is not looking too great right now.
My long answer is that the job is - despite the money - quite "blue collar". I guess an effect of it becoming mainstream among other things. A vast majority of programmers' jobs are connecting various types of tubes together and endlesly discussing minor variations of the same basic themes. You will find yourself (re-)implementing CRUD interfaces, auth flows, database models. If you're lucky you'll spend some time messing with your cloud provider of choice's various control panels or may work on massaging some data for the AI guys. That's basically it and you're getting paid for it quite handsomely so I'm not sure we should voice our concerns too loudly, but it can be soul-draining nonetheless.
What works for me is to get a job that's not micromanaged to the death. Some jobs, especially at smaller companies, pose a very interesting challenge. I guess the restricted resources, (usually) passionate leadership and sense of personal achievement makes these types of jobs more fun for me. There are usually no playbooks, no protocols. There might not even be an understanding of "user stories": you'll be the one that'll introduce it. It'll teach you all kinds of interesting things about management, planning, people etc. There can be excitement there that is completely drained out of the larger corporations. It could also be hell, so your mileage may vary.
I've maintained for a long long time that programming in the real world is more akin to a blue collar job than most people would suspect (and I worked blue collar, I qualified as an industrial electrician when I was young).
I think the way we prepare programmers for industry would benefit much more from an apprentice model than what we currently do, though of course since I'm in the UK and that would require employers investing in employees so that'll never happen.
Somewhere like Germany could make it work better though since they have a stronger program for that stuff generally.
It's such a vast field that the vast majority of programmers aren't doing bleeding edge stuff.
There's definitely overlap between those concepts. There are also some differences. I guess it depends on the nature of that specific job if it's "blue collar" or not.
I get the feeling from the poster that they are in a "blue collar" environment. Fully managed, working a specialized assembly line. No time for anything else but whipping up the next widget.
There are also SE jobs where you have to be everything. Tweaking servers, calling customers, designing and implementing backends, some frontend work, maybe even helping out with the company website. Meeting with CEOs of partnering companies. I don't see typical blue collar workers doing well in that sort of situations.
> There are also SE jobs where you have to be everything. Tweaking servers, calling customers, designing and implementing backends, some frontend work, maybe even helping out with the company website. Meeting with CEOs of partnering companies. I don't see typical blue collar workers doing well in that sort of situations.
Generally I don't know, I certainly did fine in that type of environment (has been most of my career) - I don't think it's that dis-similar to a contractor (construction not soft-eng) who has to essentially run their own business and do similar types of things.
Some of the smartest (not necessarily academically) people I've worked with where in traditionally "blue collar" roles - most developers aren't that special or that smart (and I include myself in this) - at best we have an aptitude for computers that others lack.
The problem with an apprenticeship model is that the field is moving so quickly. In many cases the younger programmers are better than the older ones whose experience is already going obsolete. The tech they learned is no longer used, and the best practices of yesteryear are now frowned upon.
> My long answer is that the job is - despite the money - quite "blue collar". I guess an effect of it becoming mainstream among other things. A vast majority of programmers' jobs are connecting various types of tubes together and endlesly discussing minor variations of the same basic themes. You will find yourself (re-)implementing CRUD interfaces, auth flows, database models.
The "blue collar" description does not fit well though, as most other high-skill, white-collar jobs (lawyers, doctors, accountants, engineers) are similarly repetetive and mundane. Typically, the company hires experts to do the same thing over and over again. You can escape that by going into research position (but even they can get quite mundane and boring, in current publish-or-perish culture) or by changing career fields every couple of years (not really realistic for most people).
> Typically, the company hires experts to do the same thing over and over again.
To me, the biggest mystery is why IT keeps tasking programmers with mundane and repetitive tasks when, unlike in other professions, the beauty of programming lies in the fact that you can abstract and automate the repetition.
Why we need million programmers building CRUD apps, why they don't have a standard already?
Same reason we have dozens of languages with very minor differences (not different paradigms), endless discussions on formatting despite opinionated linters/formatters existing, bike shedding meetings, and more.
I think we have a standard for the most part. Most of the work being done today is around expressing business requirements in code. The technical side of the tasks is automatically handled by web frameworks, database engines etc. behind the scenes.
There are multiple reasons. One of them that doesn't get mentioned much is the incentives of managers. If your team reinvents the wheel, it makes you a "technological leader". Customizing an existing standard would mean that the company does not actually need a team of developers, one of them would be enough, which implies that the company does not need you.
People keep talking about how the programmers often choose technologies to advance their own CVs, as opposed to doing what is the best for the company. Guess what, managers do analogical things all the time. It is the most reliable way to climb up the corporate ladder.
I'm not sure I'd agree that software engineering isn't looking to great right now, though I'll admit that I have a limited set of experience. Even in a boring job, there are things you can find interesting. If you're (re-)implementing the same CRUD interfaces, maybe look at some templating or code generation to cut down on the time that takes - get meta about your work and find new ways to be more productive. Up to you whether you use that boosted productivity to do more work or to spend less time working.
You could do a PhD or just work in a research environment where they support the staff taking time to do these deep dives.
My experience has been that research teams allow their members to organize their work however suits them, if that's stories then do stories, if it isn't then no stories needed.
Edit: I should note either of these will probably involve a pay cut.
Make a list of things to learn and start working through it in your off time. I put LISP on mine 22 years ago and still haven't got to it yet. New stuff keeps getting added.
In my experience, studying a topic deeply is similar to going to the gym. It requires that you dedicate time to it very regularly, and being regular is far more important than the duration of individual sessions.
Also like going to the gym, it's extremely hard to maintain the required regularity if you aren't enjoying it. The only way I have found to consistently work out is to find a deeply technical sport (BJJ, not that it matters) that I actually care to do well. It's the same with technical subjects; the only ones I'm able to study deeply are the ones I find deeply interesting.
With this in mind, my advice is as follows: approach "deep study" in a playful way, and study topics that interest you without regard for whether or not they are "useful". The utility is never far behind, anyway.
You've answered your own question: take the time to study a topic deeply.
The top answer as I'm writing this says coding is a blue-collar profession, very well, a lot of it is. I don't know if this is current, but we used to call these "line coders", nothing wrong with it, it's honest work.
But coding is also a specialist occupation with many niches. Find one you like, and master it, to the point where you're advancing the state of the art.
Congratulations, you're an expert now. The color of your collar should matter a lot less.
I love doing side projects in other languages / frameworks, mainly ones with very different philosophies. It gets me thinking in a different way, and I bring that new mode of thought back to my work.
I mainly work in React with TypeScript, and most of the devs I know rely heavily on plain objects and arrays, writing a lot of glue code to squeeze these square pegs into all the different shapes holes they need. There is a lot of opportunity to model your state and data flows using whatever programming technique I'm interested in, along with the added challenge of implementing those in a way that other devs will be able to understand. Trying to straddle this line has absolutely made me a better developer.
Some examples:
- Forth emphasizes using small, reusable "words" which you then build on top of each other to essentially create a DSL for describing your app / data.
- Rust has a great type system which improved my understanding of TypeScript. It also has really sexy monadic data types like Either and Result that you can implement in TS/JS.
- Elm is a pure functional language that compiles to HTML CSS and JS. Any amount of time spent with Elm will make a better React dev.
- Lua is close to JS but lacks a lot of the niceties. If you want classes or arrays or anything like that, you pretty much have to implement them yourself.
None of my side projects are world changing, but the effect they have had on my day-to-day code is significant. Programming teaches you new modes of thought, and the more you are aware of what goes on in these other parallel worlds, the more fun it becomes to try and tackle problems that are hard in your language / framework, but easier in others.
I also spend a lot of time listening to technical podcasts. I always recommend that JS / TS devs listen to the LambdaCast, which hasn't produced an episode in 3 years, but is still a very valuable resource. I also like the ArrayCast (array programming language nerds talking about array programming).
I'm currently in the middle of reading "So Good They Can't Ignore You" by Cal Newport. In Chapter 7, he tells a story of chess masters which compares those who trained by study and those who trained by competition. The conclusion was those who trained primarily by study vastly dominated. The reason being that by study they could always exist in the zone of proximal development whereas the other group was subject to the peers they were arbitrarily paired with.
What at your job pushes you just beyond your current skill level?
A competing explanation is that the chess masters for whom study is particularly advantageous are also those who happen to be able to dominate their peers. Magnus' capabilities seem to be a testament to that. There is also the aspect of computer analysis multiplying the effectiveness of chess study versus real life competition.
In coding, this is an example of boot camp (project based) vs CS degree (or long term self-study). In the last 5-10 year in my job, I saw significant amount of boot camp grads who can make CRUD/ML apps fast and relatively clean. As soon as anything goes wrong, boot camp grads would look for another technology to solve symptom of the problem without understand the cause, while the second group consistently perform better by working through the problems and develop solutions.
Run a non-commercial side project (Maybe open source)
A big part of learning is making mistakes and learning from them. As you grow in seniority, mistakes become more expensive in money and or stress. Trying new things on stable products in big companies is hard. So how do we keep learning? How do we get updated? How do we try new stuff to be seniors on it five years from now? Run a side non-commercial project.
Why no commercial? I will get deeper into this soon, but if people are paying for it, downtime, bugs, and instability are not quite acceptable. While learning, you probably have all of those, sometimes multiple of them, at the same time.
To experiment and make mistakes that don’t cost me a lot of money or cause too big a problem, I must have a side project.
I wanted to learn rust deeply, and it would be impossible to do so if I had not started NunDB. On Nundb, I can work 10 hours a week or no hours at all without any problem. If I have one hour to code, that is enough for me to do something on NunDB, it requires much more coding than my other two activities, and I still only have a hand full of people using it and only one single critical application, so there I can experiment, learn, have fun.
> And instead take the time to study a topic deeply?
Three options:
1. Go back to university, get a PhD
2. Go work for a research institute (may require (1))
3. Become a subject matter expert (SME) and focus on one area of the business
> I find myself finishing endless user stories but my technical skills seem stagnant
Well, you already aren't a pragmatic programmer then. You should be constantly learning, constantly looking for new and interesting work (internal or external to your employment). Engaging with your management to get put on the more interesting tasks.
Want an example of a pragmatic SME I knew? He was a EE, wanted to do software. So he bought a couple embedded dev boards and started learning. He brought in a demo to the software manager and said, "I want to be on your team, here's what I can do now." The manager was impressed and they moved him over to that team. He was truly a subject matter expert, and also pragmatic. Funny, no conflict between the two.
72 comments
[ 0.24 ms ] story [ 137 ms ] threadAs a manager, I actually really like working with devs that just put their heads down and churn through tickets. My focus is trying to implement the business strategy and having developers that allow us to execute by building what is needed is excellent.
Developers (and I include myself in this bucket as I am 1000% guilty of it) are very easily distracted by The New Shiny, and sometimes it's irresistible to dive off into rabbit holes under the guise of 'learning new things'. Too many times I've ended up with massively over-engineered solutions that use experimental stuff that adds business and/or operational risk.
I know how soul-destroying it is to simply sit there pulling ticket after ticket though so I carve off time explicitly for self-directed learning & [what I hope are] fun little skunkworks projects. My goal is to try to find a balance between executing business strategy and continual improvement and development (heh) of my team.
But your solution sounds awesome. I would love my team to get more involved in open source projects & might suggest this as something to do as part of their usual workload. I wish I'd spent more time doing this when I was more actively programming myself.
Possibly your team has added workarounds and technical debt to your codebase for issues in your dependencies, that is probably a good place for them to start. It is also nice to give back to projects by working on "papercuts"; things that are easy to fix but annoy lots of people (Ubuntu did this for eg). Working on bigger stuff is good too, like fixing all crashes or adding important features from the roadmap etc.
https://ubuntu.com/blog/tag/papercuts https://wiki.ubuntu.com/One%20Hundred%20Papercuts/Mission
Some companies have a "20% time (or X hours) on open source" policy, which is great for the sort of issues mentioned above.
Some open source projects have a list of ways companies can support them with resources (like sponsorship, download mirrors etc), for example here is the one for Debian:
https://www.debian.org/intro/help#organizations
It is a good idea to reword your employee contracts to mention the company policy on open source and give employees copyright over their contributions to open source projects. Some projects like Samba do not allow corporate copyright ownership. For other open source projects, having a diverse copyright holder base of individuals and a broad contributor community helps protect projects (at least those that are copyleft) from license and other changes brought on by company acquisitions, industry competition and other corporate influences.
https://sfconservancy.org/contractpatch/
If you want more separation between your company software and open source software, an Open Source Program Office or just an internal "open source team" is a good idea, although it is always a good idea for lots of folks to have open source experience, so rotating other employees through the team for periods/percentages of time might be good too.
https://blog.opensource.org/what-is-an-open-source-program-o...
When setting up an internal "open source team", the FOSSjobs website and the other job aggregators linked from the FOSSjobs resources wiki might help you hire new open source folks.
https://www.fossjobs.net/ https://github.com/fossjobs/fossjobs/wiki/resources
PS: if you need advice more specific to your situation, see my profile.
We have this as an unwritten policy at the moment (... that I have been trying to get formalised for a while & need to follow up!).
> It is a good idea to reword your employee contracts to mention the company policy on open source and give employees copyright over their contributions to open source projects.
This is an excellent idea - thanks.
> If you want more separation between your company software and open source software, an Open Source Program Office or just an internal "open source team" is a good idea, although it is always a good idea for lots of folks to have open source experience, so rotating other employees through the team for periods/percentages of time might be good too.
We are not quite big enough (yet) for this, but something like this is already on our radar. We have a pretty major dependency in our stack that is starting to look a bit abandoned & have been idly discussing the possibility of hiring someone to maintain it.
Appreciate the feedback!
If you feel you don't have access to real problems, go and work for tech support a bit. You'll get them eventually.
Regarding your question, why not find a new job / role? For example, I was curious about VR but knew nothing about it. So I got a VR gaming company to hire me as a freelancer at a much reduced rate for a few weeks. It was a great way to delve into the technical aspects of the space. Alternatively, you could start a hobby project where you go into depth.
1: https://pragprog.com/titles/tpp20/the-pragmatic-programmer-2...
adjective: pragmatic
In the context of programming this implies reaching for a ready made solution rather than re-inventing the wheel, avoiding implementing unused features, not spending time fighting code formatting and so on.Anyway, I think OP is confusing the term too
However, as GP points out, it's such a recognisable phrase with a slightly tangential or at least specific meaning that OP's question probably isn't quite what people expect (or they don't know what to expect) from the title.
Given the definition you wrote, what's the difference between a pragmatic programmers and an experienced one?
Examples:
Instead of using a middleware between a web server and an application, write one (of course it was easier when I did it in 1994.)
Instead of using an IDE that magically recompiles Java and brings you to the errors, write the code that monitors the file system and runs javac, etc (2005).
Instead of using a CMS, write one (did it in Perl in the 90s.)
Instead of using a JS framework, write one (I kind of tried but no time for it.)
You'll find something that's relevant today and for your work.
There is no need to go on for too long because this approach is good for learning but bad for productivity. The problems to solve and the plausible solutions get clear pretty soon. The problem, as always, is the time.
https://dylanlott.com/orderbook
If you’re interested in reading more. I’m planning a part 2 update to it soon.
Edited to fix my link.
That's it.
If you want anything else from your programming career then you'll need to do it yourself.
Inb4 "That's not Scrum" yes, we know.
I've worked, briefly as a contractor, in one these places before: full day sprint planning, 3 hour retrospectives, 1-2 hour standups, breakdowns of simple stories into sub stories etc. etc. ... but I didn't blame scrum and points for the fact I was miserable.
Certainly it's not 'scrum' per se that bothers me - I was carefully not saying 'agile' because I think that's fine it's just the typical method of 'doing it' that I meant, but seem to have fallen into a different trap in the process - but it is the breaking down of the job into actionable work pieces, 'tickets', and some of the ceremony around that, whether strictly 'scrum' or not.
But that's just me right, obviously some (lots of) people like it! My initial comment was that it's surprising (to me) how few seem to not like it, so I'm perfectly aware that's just my (and some few others') opinion.
I guess it's a continuum ... I have people on my team right now that are working on a single story, other people who have a few dozen this sprint. If your team is breaking down what would be a single story on my team ... I could see that being annoying.
Now, the developer working on that story has a breakdown of tasks that they are managing as sub items in the story, but that's not getting managed with story points or any other heavy weight system.
I'm reminded slightly of an article submitted here recently - https://martinfowler.com/articles/bottlenecks-of-scaleups/03... (though they're not really discussing motivation as such) - it's the detachment of engineering from product, I suppose. Little 'ownership' of or time to spend on thinking about the product experience, just 'do this', 'add that'. If I compare to people I know in other professions - accounting, doctors, tax - they all work more directly with a client or case, manage their own work. Of course they have managers too, but that relationship is more like 'I need some help with this problem that has arisen, let me now brief you on what I've been doing because otherwise you have no context' or longer-term performance etc. - not 'what tiny thing(s) did you do yesterday and which tiny thing(s) will you do today' every bloody morning.
This is only useful if you want to ship changes iteratively. If you're working a on a big blob of a thing that can have waterfall-style estimation and delivery then you'll avoid all that.
> it's the detachment of engineering from product, I suppose
This is more likely the cause. The emergence of product as a ruling class over engineering is a problem. Product is a useful concept, but I think we've all assumed only a person with a Product job title can be a product owner in a team, when I think Product adds much more value as a slightly more distant integration point for engineering, marketing, sales, customer support, legal, etc.
It seems that among the cool kids, "waterfall" is considered a bad thing that everyone should avoid.
I admit I miss the days when I could have spent weeks working on a project without being interrupted by daily "agile" meetings.
I think if there's no team you need to talk to very often and you're working in a pretty static environment then you should be fine. It's just that a lot of those nice problems are harder to come by these days.
Those are not common in my experience either. Perhaps I've just avoided working at depressing places :-)
I've never worked somewhere which actually named things 'stand-ups', 'points', 'stories', 'retros', or even 'sprints'. I'm familiar with the concepts, both from general reading, and thanks to someone who taught me all about Scrum, which was enough to put me off both Scrum and it's perverted form of Agile. If I hear those things mentioned in an interview, I soon have more questions, because there's "good Agile" and "bad Agile".
Sprints have occurred, in that there have been places with regular meeting and review cycles. That can work really well, imho. But even then, from the sound of it I've avoided the kinds of places where people feel under constant 2-weekly pressure to count up story points and highlight competitive ticket metrics.
I have a feeling I'll be starting at a place like that soon though. They use Jira, require a ticket for every PR, and by the sound of it are doomed to take a very long time to do anything. The tickets are written for accountability and reporting every change to management, so not written for developers. The approach smells like an anti-pattern to me. I don't expect to stay long; it's just a contract. I wouldn't choose a place like that for a long-term position, but I'm looking forward to the experience to find out what it's like with an open mind. I was hired as an interim team lead, but politics already changed what the role is since signing, and it's also been made clear that TLs there don't get to decide how anything is actually done. We'll see. I tend to bring new energy to a system.
I've used scrum while building cool VR tools for Architects, my Research Scientist was developing new algorithms and we were building stuff like real time collaboration with view tracking and hot spot overlays, all in a scrum framework.
This is like saying "office chairs makes miserable factory-like work", Scrum is just a management tool. If your manager is making your life miserable, that's not scrums fault.
/e: also I'm very interested in what your specific "anything else" would be.
It does nothing to solve fundamental issues inherently. But these fundamental issues are well known, so any method not addressing them is rather weak by default.
I know "but that's not agile" is a tired meme at this point, but if you read something like for instance the pattern work by guys like Jim Coplien and Sutherland [1], then Scrum as outlined by these communities of practices sounds pretty sensible. Just some random excerpts:
> Use Small Teams of people working on serialized work rather than striving for false parallelism.
> The Development Team organizes itself to get its work Done. The Development Team is solely responsible for how it does its work.
> Explicitly allot time for interrupts and do not allow more work than fits within the allotment.
> Create ad-hoc “birds of a feather” groups for each area of significant enterprise core competency or developer interest, where interested parties can trade notes on technologies, domain knowledge, and processes that are key to enterprise advancement.
etc.
[1] http://scrumbook.org/
My long answer is that the job is - despite the money - quite "blue collar". I guess an effect of it becoming mainstream among other things. A vast majority of programmers' jobs are connecting various types of tubes together and endlesly discussing minor variations of the same basic themes. You will find yourself (re-)implementing CRUD interfaces, auth flows, database models. If you're lucky you'll spend some time messing with your cloud provider of choice's various control panels or may work on massaging some data for the AI guys. That's basically it and you're getting paid for it quite handsomely so I'm not sure we should voice our concerns too loudly, but it can be soul-draining nonetheless.
What works for me is to get a job that's not micromanaged to the death. Some jobs, especially at smaller companies, pose a very interesting challenge. I guess the restricted resources, (usually) passionate leadership and sense of personal achievement makes these types of jobs more fun for me. There are usually no playbooks, no protocols. There might not even be an understanding of "user stories": you'll be the one that'll introduce it. It'll teach you all kinds of interesting things about management, planning, people etc. There can be excitement there that is completely drained out of the larger corporations. It could also be hell, so your mileage may vary.
I think the way we prepare programmers for industry would benefit much more from an apprentice model than what we currently do, though of course since I'm in the UK and that would require employers investing in employees so that'll never happen.
Somewhere like Germany could make it work better though since they have a stronger program for that stuff generally.
It's such a vast field that the vast majority of programmers aren't doing bleeding edge stuff.
I get the feeling from the poster that they are in a "blue collar" environment. Fully managed, working a specialized assembly line. No time for anything else but whipping up the next widget.
There are also SE jobs where you have to be everything. Tweaking servers, calling customers, designing and implementing backends, some frontend work, maybe even helping out with the company website. Meeting with CEOs of partnering companies. I don't see typical blue collar workers doing well in that sort of situations.
Generally I don't know, I certainly did fine in that type of environment (has been most of my career) - I don't think it's that dis-similar to a contractor (construction not soft-eng) who has to essentially run their own business and do similar types of things.
Some of the smartest (not necessarily academically) people I've worked with where in traditionally "blue collar" roles - most developers aren't that special or that smart (and I include myself in this) - at best we have an aptitude for computers that others lack.
The "blue collar" description does not fit well though, as most other high-skill, white-collar jobs (lawyers, doctors, accountants, engineers) are similarly repetetive and mundane. Typically, the company hires experts to do the same thing over and over again. You can escape that by going into research position (but even they can get quite mundane and boring, in current publish-or-perish culture) or by changing career fields every couple of years (not really realistic for most people).
To me, the biggest mystery is why IT keeps tasking programmers with mundane and repetitive tasks when, unlike in other professions, the beauty of programming lies in the fact that you can abstract and automate the repetition.
Why we need million programmers building CRUD apps, why they don't have a standard already?
Same reason we have dozens of languages with very minor differences (not different paradigms), endless discussions on formatting despite opinionated linters/formatters existing, bike shedding meetings, and more.
People keep talking about how the programmers often choose technologies to advance their own CVs, as opposed to doing what is the best for the company. Guess what, managers do analogical things all the time. It is the most reliable way to climb up the corporate ladder.
My experience has been that research teams allow their members to organize their work however suits them, if that's stories then do stories, if it isn't then no stories needed.
Edit: I should note either of these will probably involve a pay cut.
Also like going to the gym, it's extremely hard to maintain the required regularity if you aren't enjoying it. The only way I have found to consistently work out is to find a deeply technical sport (BJJ, not that it matters) that I actually care to do well. It's the same with technical subjects; the only ones I'm able to study deeply are the ones I find deeply interesting.
With this in mind, my advice is as follows: approach "deep study" in a playful way, and study topics that interest you without regard for whether or not they are "useful". The utility is never far behind, anyway.
The top answer as I'm writing this says coding is a blue-collar profession, very well, a lot of it is. I don't know if this is current, but we used to call these "line coders", nothing wrong with it, it's honest work.
But coding is also a specialist occupation with many niches. Find one you like, and master it, to the point where you're advancing the state of the art.
Congratulations, you're an expert now. The color of your collar should matter a lot less.
Parts of the code nobody wants to touch. Tasks that seem too big.
Work on those. Attack the hard problems.
And if your work code doesn’t have those hard problems, you probably have a lot of free time, so get a compiler course somewhere or something.
I mainly work in React with TypeScript, and most of the devs I know rely heavily on plain objects and arrays, writing a lot of glue code to squeeze these square pegs into all the different shapes holes they need. There is a lot of opportunity to model your state and data flows using whatever programming technique I'm interested in, along with the added challenge of implementing those in a way that other devs will be able to understand. Trying to straddle this line has absolutely made me a better developer.
Some examples: - Forth emphasizes using small, reusable "words" which you then build on top of each other to essentially create a DSL for describing your app / data. - Rust has a great type system which improved my understanding of TypeScript. It also has really sexy monadic data types like Either and Result that you can implement in TS/JS. - Elm is a pure functional language that compiles to HTML CSS and JS. Any amount of time spent with Elm will make a better React dev. - Lua is close to JS but lacks a lot of the niceties. If you want classes or arrays or anything like that, you pretty much have to implement them yourself.
None of my side projects are world changing, but the effect they have had on my day-to-day code is significant. Programming teaches you new modes of thought, and the more you are aware of what goes on in these other parallel worlds, the more fun it becomes to try and tackle problems that are hard in your language / framework, but easier in others.
I also spend a lot of time listening to technical podcasts. I always recommend that JS / TS devs listen to the LambdaCast, which hasn't produced an episode in 3 years, but is still a very valuable resource. I also like the ArrayCast (array programming language nerds talking about array programming).
What at your job pushes you just beyond your current skill level?
A big part of learning is making mistakes and learning from them. As you grow in seniority, mistakes become more expensive in money and or stress. Trying new things on stable products in big companies is hard. So how do we keep learning? How do we get updated? How do we try new stuff to be seniors on it five years from now? Run a side non-commercial project.
Why no commercial? I will get deeper into this soon, but if people are paying for it, downtime, bugs, and instability are not quite acceptable. While learning, you probably have all of those, sometimes multiple of them, at the same time.
I wanted to learn rust deeply, and it would be impossible to do so if I had not started NunDB. On Nundb, I can work 10 hours a week or no hours at all without any problem. If I have one hour to code, that is enough for me to do something on NunDB, it requires much more coding than my other two activities, and I still only have a hand full of people using it and only one single critical application, so there I can experiment, learn, have fun.
Three options:
1. Go back to university, get a PhD
2. Go work for a research institute (may require (1))
3. Become a subject matter expert (SME) and focus on one area of the business
> I find myself finishing endless user stories but my technical skills seem stagnant
Well, you already aren't a pragmatic programmer then. You should be constantly learning, constantly looking for new and interesting work (internal or external to your employment). Engaging with your management to get put on the more interesting tasks.
Want an example of a pragmatic SME I knew? He was a EE, wanted to do software. So he bought a couple embedded dev boards and started learning. He brought in a demo to the software manager and said, "I want to be on your team, here's what I can do now." The manager was impressed and they moved him over to that team. He was truly a subject matter expert, and also pragmatic. Funny, no conflict between the two.
https://bootstrappable.org/