I’m a designer who codes, and for those who have had trouble expressing the value and finding a role that enables both, here is how I’ve positioned it:
As the primary designer for a product, who can also implement the design - the amount of communication needed between design and engineering literally evaporates.
I tell my devs they can build an ugly v1 of any feature simply for the sake of speed, and I’ll go in after to clean it up and make it look consistent. they don’t need to waste time with CSS.
Design changes so often after implementation, that I don’t even keep a living design file, most changes happen directly in code. If I do need to design something as part of a pitch or meeting material I take a screen shot of the product and just modify that.
Having worked as only a designer, and then only as an engineer, I can’t express how much faster my team is when design is part of engineering.
Speed is most critical to startups, I’ve always found interviewing with startups and presenting this skill set is highly sought after when expressed properly.
Hey everyone - today we launched a demo for people try our “ChatGPT” like tool (but not using ChatGPT) for asking questions about recent Wall Street events. Would love any feedback!
Our platform analyzes events relevant to investors, company financials, and textual data to give investors an edge.
Our back end consists of Python and node based micro-services. We also utilize machine learning and big data to analyze equities and events, and to transcribe and analyze audio. We capture and re-broadcast audio via WebRTC, SIP, HLS, DASH. Our APIs are a mix of REST and GraphQL. We utilize Docker, AWS services, Terraform.
You may be a fit if:
* 3-5+ years of professional software development experience, ideally some of which was spent in a startup or fast-paced environment, but this is flexible for the right candidate
* You enjoy thinking about systems design, and diving deep into the details
* You are a self starter and can make decisions quickly
* You have good communication skills and can support project stakeholders
* You have experience working with Python, SQL, GraphQL, AWS, Docker, ElasticSearch
* It would be amazing if you had WebRTC, SIP, telephony, experience, but is not required
reach out to elliot [at] aiera if you're interested!
Obviously you’re entitled to your opinion. We don’t have jr. members on our team, but if we did, they’d be assigned a project like anyone else. If the project was a bug, that would be reasonable. This process is for the intern and every other dev to avoid reading a giant list of potentially stale bugs anytime they have a short gap between work. it keeps them working on A) what they were assigned, or B) something small that people have been clamoring for.
Why do you have a giant list of potentially stale bugs?
The policy described in the linked-to article is roughly equivalent to saying that every bug/issue must be passed to someone, who is in charge of that issue, including closing them.
The main difference is that there's a single tracker instead of "personal workload lists".
What happens to the workload on a personal list if the person is unexpectedly out of work for a month?
Now that I've read a bit more:
> Developers will only want to hear the same request so many times, before losing whatever is left of their sanity, and deciding to address the issue.
What happens if the stakeholder's sanity runs out first?
> Why do you have a giant list of potentially stale bugs?
Most places I've worked have a bug log? Priorities balance between new feature development and fixing bugs / tech debt. If a bug isn't high priority, or the feature it was about has been changed or removed, the bug might now be stale - but still exists in a list somewhere.
> The policy described in the linked-to article is roughly equivalent to saying that every bug/issue must be passed to someone, who is in charge of that issue, including closing them.
It's the opposite, it's saying that if the bug / issue isn't easy enough to be solved right then, it needs to be reported again later, or added to the official prioritized road map.
> What happens if the stakeholder's sanity runs out first?
I think my earlier rhetorical question came across as one of inquiry.
Most place have a bug log. Some of the OSS projects I'm involved with have bugs I've submitted over a decade old.
My comment was meant to lead in to how a centralized bug system is not the issue - it's one of process. If a bug comes in, and either people accept a bug or close it right away, then it's the same as having a personal work list.
Except that the failure modes, like when people suddenly must be on leave for a month, are less severe.
(With the proviso that some people use personal work lists with a different interface than the centralized system might offer.)
I have worked with only 2 architects who have made me understand what it means to be a good architect. 1 they make sure the code is organized in a meaningful way - consistently, and using places and patterns which make it feel easy and obvious.
2, they determine the code conventions used in a project and help to enforce them with tooling (git hooks, generators, PR reviews etc).
This helps scale a team, and build a cohesive lightning fast unit.
I’ve worked with fantastic devs in the past who had no real understanding of this kind of “architecture”, and as a team the difference was clear.
That’s not architecture. The tasks you describe are those of a development lead or dev manager.
An architect might also be a dev team lead, in which case they might have such responsibilities, but the point remains that such detail oriented aspects of the development process are what the dev team lead does.
The job of a building architect isn’t to ensure the builders know how to use their tools and keep them neat, and to ensure they measure straight lines.
The role of the architect is to design the system at a high level to meet a myriad of business and other requirements such as performance security reliability interoperability extensibility etc etc
The architect is politician, diplomat, technical strategic planner, salesperson.
I guess every company defines the architecture role differently. When I worked as an IT architect we never talked with developers or even looked at their code. There were 2000+ developers and less than a hundred architects. What it sounds like you are describing is a senior or lead developer role.
Again, those aren't architectural activities. They're organizational, so the responsibility of a team/group leader, or an SDLC facilitator.
Architecture is about the function of the system and how it interacts with its environment. That requires understanding both of those elements, functionality, and environment.
These are how you appear to developers as a _useful_ architect. Sure, there is a lot of other tasks that they do involving design and planning for the future - but the only way as an architect to actually impact software development is to take a hand in building it.
Every architect that I have worked with (my title has been "architect" for awhile now) that didn't spend at least 50% of their time in code was more or less a pretty picture generator - whose documents were ignored by anybody actually building the application.
I think the big point is that developers should trust you. One of the best ways to achieve that is to participate in coding a little. My experience says the architect should avoid the critical coding and focus an quality topics. For example, style unification or linter fixes.
A corollary is that you also need the trust of other stakeholders.
For managers I'd say you need to communicate confidently and deliver. The trick with delivering is to lower expectations early.
It depends on the organization what other stakeholders there are. That is a good separate point actually: Know your stakeholders. Make a list and ask them about their expectations.
> they make sure the code is organized in a meaningful way
> code conventions used in a project and help to enforce them with tooling (git hooks, generators, PR reviews, etc).
Finally, something where I can say "ha! that's exactly what I'm up to now". This right up my alley, and I'm hoping to make some good progress soon here.
A little over a year ago I was building an app, and decided I'd have literally no backend at all. I wanted to build something fast and ship it to the appstores as quickly as possible to go through the process. After I launched, it was featured by apple and was getting thousands of downloads per day. Users wanted to be able to save their data across devices - but it wasn't something I really had time to build in the ways I had in the past. I had heard what Dark was up to, and was lucky enough to join the beta. Dark now powers the backend for my app (nzd.life) - and I really can't express just how amazing it is to use. We added the functionality in just a weekend with a handful of LOC. Dark really is a game-changer. For any entrepreneur / dev who wants to move fast and ship things, they should try Darklang ASAP.
This is an awesome case study. Thanks for sharing. I was having trouble coming up with good use cases for this, but this makes a ton of sense. It's basically like a much more advanced, better Firebase/Lambda/Google Cloud Functions/Azure Functions.
I am in the same boat. I often build apps that are pretty much 98%+ clientside, but there are just a few routes I need for the backend that would add a lot of value, but if I were to create those I can no longer sleep soundly at night because suddenly I have to worry about online storage security, pingdom checks, deployment pipelines, etc.
Now I get where this could be really, really useful.
